Re: Shapes layout proposal



John/James L./Andre:

I like (and have argued for) the idea of a 'mini-DOM' API, based on a subset of SVG, being used as the internal structure of these Ur-Shapes. For the arbirary additional properties, we need a portable, language-agnostic set of datatypes, which can come from XML Schemas. (Note: the types in the schema spec are acutally fairly close to those in the Dia std. props library, with the exception of the UI elements, so much of the code can probably be adapted from there and/or made to work with std. props objects).

Basically, I see the shape definition syntax as an extension of the current custom shapes code to allow the attachment of addtional properties that may or may not have any direct visible rendering, but are exposed via the 'mini-DOM' to C or scripting code that gives the objects their complex behavior. All of the I/O can be handled by the standard XML library, and the object interfaces can just be a deifned by a handful of callbacks, which are based on an event/listener model.

The subtle difference between this and the current custom shapes only become apparent when this behavior-modifying code is present; the remainder of the time, they will simply be rendered just like the current SVG-based custom objects, with their properties editable via the standard mechanisms. This also means that a user opening a diagram with these object types will only need the XML definition to read them, not the C/Python/whatever behavior code. Believe me, this is a good thing -- an XML file is very portable, and very easy to distribute, compared to a .so or .DLL file.

As to C++ being the implementation language, I'm going to have to second Andre and whoever else balked at it: we want to interoperate with Dia, not replace it. For example code, we have several sources: the standalone Dia Canvas available from GNOME CVS or SourceForge, the Gill SVG-viewer project, and the Sketch vector editing program (which has the further advantage, to my mind, of being almost entirely written in Python, with a few C libraries to handle performance-intensive things like rendering and event dispatching).

Lennon Day-Reynolds







[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]