Re: Shapes layout proposal

[John Palmieri <johnp martianrock com>]

>
> The latter, in my mind.  While the looks of the UML object can be made with
> the above-mentioned SVG extension, the functionality of the attributes,
> operations and interfaces are more complex than would be workable in XML.
>
> The rework that would be nice at some point (probably after GTK 2.0
> rewrites) is to make it easy to combine SVG shapes and C code.  Perhaps
> that is what you were thinking of?  'Twould be tricky, IMHO.
>
> Again, sorry for getting into flaming mode, I thought you were proposing
> much more extensive changes.
>
>

Yes SVG shapes combined with C code for behavior.  Right now we want to work on
the layout issues and then move to scripting which could be done with C using a
standard C interface for callbacks.  Or it could use python, perl, etc. (Anything
with bindings to the standard C interface) .

Let me clarify where I want to go with this:

-Don't mess with the current SVG shapes - they work fine.
-Extend the SVG shapes with a new DTD for widgets and containers.
-Add the notion of ID's or named components to the Shape files
-Add a C interface for querying for ID's.
-If ID's are hashed one does not have to search the whole XML tree for access to
an element
-All C callbacks expect a pointer into the XML structure pointing to the node that
tripped the event. This allow for traversing of the tree if need be or simply
acting on the attributes of the node, which is no slower than querying for a
property.
-For speed, pointers to frequently accessed data such as user inputted text can be
gathered by the callback and used instead of querying the XML structure every time
a change is made.
-Saved files would save out the whole Shape allowing other programs to load a dia
diagram with a simple filter.  This also allows for scripts outside of Dia to use
the saved file to say, produce C++ files from UML descriptions.

Of course we must first work on layout and then move on to designing a way to deal
with functionality; so this is all a quick snapshot of what the future may hold.
It is just an idea of what I am think of.   As for waiting till Gtk-2.0, you have
a group of developers ready to start now.  Even if the changes don't get in until
Dia for Gtk-2.0 is finalized we could provide proof of concept and work out issues
way before then.

--J5