More Ideas for Sketch API
I’ve just submitted a position paper to FlexiTools’2010, in which me and Simone outline our ideas for the Sketch API, which i’m carrying on with Chris and Mariot.
Take a look at the paper:SKETCH: Modeling Using Freehand Drawing in Eclipse Graphical Editors
The main idea is the approach of the modeling task as a twofold process — one of freely sketching models with little interruption from the system; and another more formal, “classic modeling”, recognizing the elements drawn by the user right away, having as output a model in its canonical representation.
By letting users draw the model using their own graphic representation, we are allowing the GEF/GMF editor to be more flexible regarding its visual notation. For instance, assuming a simple model with the elements named flower, sun and cloud — they might be connected and generate an output or might serve as input for other models. A user might draw the flower element, for instance, in infinite ways, having any number of petals, with or without stem, and so on.
This allows the creation of a “graphicless model”, without predefined visual counterparts to the model elements, just elements and relations — the user would choose how elements will look like. That means the .gmfgraph would just hold the canonical representation, but the real one will be the user’s.
So, on Eclipse GEF/GMF frameworks side, some minor modifications will need to take place:
- The underlying model (Ecore?) will need a generic element to serve as an ‘unrecognized’ element, to be created at the model while the user does not signifies it as anything
- make the editor flexible enough to hold any graphic representation for it’s elements, representing it using an SVG with the sketch. Also, this approach can also be used to make annotations on existing models, since the user might be able to create an “annotation” element.
Those are all feasible, so little adaptation would be needed to plug sketch onto GEF/GMF editors 🙂
Don’t you think?