Re: Constraint solver for drawing elements in Gaphas
Arjan Molenaar
On 7 Feb 2011, at 01:39, John Pye wrote:
> Hi Arjan
>
> On the ASCEND project, we're revisiting the issue of our canvas-based
> modelling GUI, and in particular, how we have have custom-shaped
> elements placed on our modelling canvas using Gaphas.
>
> http://ascendwiki.cheme.cmu.edu/Canvas-based_modeller_for_ASCEND
>
> I'm not sure if we already discussed some of these ideas: there are a
> couple of options open to us; we could have little bitmap elements, or
> else we could have SVG elements. In both of these cases, the coordinates
> of ports would have to also be defined, together perhaps with some
> labelling details.
>
> Another option is to have the elements described in terms of lines,
> boxes, arcs, etc, together with associated constraints that are actually
> managed by Gaphas itself. This seems to be a nice approach, because it
> would allow clean drawing of all elements at all scales, and would allow
> 'smart' elements that would resize/scale/stretch in sane ways, for
> example a diagram of a pipe could be stretched without causing the
> circular ends of the pipe to be stretched into big flat ellipses.
Funny you ask this. It has been on my mind for quite some time already.
> In order to use this latter approach, though, it seems that the size of
> the constraint-solver problem would grow enormously; perhaps by a factor
> of ten, and I can see that that might slow the user experience down
> quite badly.
The current implementation of the constraint solver is pretty capable of maintaining connections, but it has it's limitations, although I haven't reached those yet. Although Element is also registering a few constraints currently. That seems to work fine (4 constraints per element).
> As a result, I wanted to ask if you had any clever ideas for ways that
> we could 'lock' the geometry of our elements, so that the constraint
> solver doesn't have to re-solve unless an element by itself is actually
> being resized.
The constraints solver is written in a way it only resolves the constraints who's variables have been changed. For these kinds of diagrams I would expect this to scale pretty well.
> The downside of the Gaphas-based approach is that we then need some kind
> of nice way to draw the icons that we then need. We could hand-code
> them, but that would quickly become tedious, I imagine. Basically we
> would need a little toy constraint-based drawing program... or could we
> cleverly re-use some other tool?
The most obvious choice IMHO would be SVG. However, you run into the problems you already describe. In my case this also includes identifying editable text and do element sizing accordingly. Those can be countered by adding extra elements to the svg (using a separate namespace or something).
In my case I want users to apply a stereotype icon for an item. this stereotype one should draw using tools like Inkscape. You don't want to code complex images, with color blending and all in Python. As far as I know there is no library that can execute a bunch of Cairo commands based on a SVG file.
> Any thoughts? Does Gaphas have any provision for this, or is it
> something that could be added? Or is the constraint solver already smart
> enough that we don't need to worry about speed issues here?
About the constraint solver: I'd like to replace it with libavoid, but Python bindings are not feasible (no way to hook into the libavoid lifecycle), so it should be a rewrite, I guess...
Regards,
Arjan
> Cheers
> JP
>
> PS feel free to reply CC to the gaphor group, if you think it is of
> interest.
>