Re: Shapes layout proposal

[Lennon Day-Reynolds <lennon kestrel edu>]

Okay, I just have to weigh in here...this looks like too much fun.

Cyrille Chepelov wrote


> Have you ever read libxml C code ? I prefer a thousand times a struct member
> access rather than the contorsions lib/dia_xml.c has to do to access its
> data, thank you.


Just for comparison, let's take the following snippet of code. If 
objects in Dia were internally represented using the libxml tree 
interfaces, then the following would work as a 'get_state' function for 
*all* object types:

-- C --

typedef xmlElementPtr DiaObj;
typedef xmlAttrPtr DiaObjState;

DiaObjectState dia_obj_get_state(DiaObj obj)
{
   return (DiaObjState *)xmlCopyPropList((xmlNodePtr)obj, 
obj->attributes);
}

-- end C --

Hmm, quite the contortion, no? Of course, similarly mindless methods 
could be used to copy objects, save and load diagrams, send single 
objects to a plugin or external process, etc. *That* is why people love 
XML -- a simple set of interfaces gives you a flexible starting point 
for internal data structure manipulation.


> The proper equivalent of HTML files in dia terms is .dia files -- already
> XML. Shapes and objects are the image in HTML land of individual visual
> elements (ie, images, chunks of text, separators, from controls and tables). 
> When you want to add on your site a special widget the W3C hasn't thought about, 
> you basically write another object in a compiled language, which conforms to a
> specific API (java applets / COM+Windows objects). DHTML isn't a silver
> bullet, and it's very quickly pushing CPUs to their limit (see what happens
> in the big Bugzilla query page when you select the dia module -- if your
> code is going to make complex objects that slow, then no thanks !)


But the browsers themselves use the DOM internally -- how else would 
they provide DOM bindings in JavaScript? If you write a plugin in C++, 
you're using the exact same interfaces. Standardizing on a DOM-based API 
for data manipulation isn't what slows DHTML down -- it's the use of 
JavaScript, an interpreted-only, dynamically typed, home-grown scripting 
language. I don't think anyone's suggesting that Dia should support 
JavaScript in its XML file format, so we should be pretty safe.


> On the complexity side, I'm absolutely not worried about current *shapes*
> (ie, static objects). They work already well, adding (yet another) a
> standard way of accessing properties can't really hurt. What worries me is
> your plan to "get rid of [objects]" in favour of an overextended shape
> format. I claim that defining a file format able to have as much flexibility
> as the current offering of binary objects [...]

> is going to lead to XML files much more
> complicated than the reasonably readable C files we have now [...]


XML is not a programming language, and there certainly isn't any way to 
wholly replace the functionality of C in defining object *behaviour* 
with it. As you said, though, there's a serious lack of standardization 
in the properties manipulation code, and this is where an XML-based 
approach helps. Using the DOM, (or the libxml tree interfaces, which are 
basically a baby-DOM) you have a very simple, understandable set of 
interfaces which can treat each and every object in a diagram as an 
opaque data structure, which can then be passed around, saved, updated, 
etc., without knowing a damn thing about its implementation.


> The W3C hasn't defined a way to describe new controls in an XML-based
> format, has it ? Perhaps there's a reason... 


Think XForms, SVG, SMIL, etc., etc. They're all XML-based standards for 
adding functionality to applications, and all are build with versioning, 
feature set extension and filtering, etc., basically leaving it wide 
open for implementors to add their own widgets, objects, or structures.


> One area where I see the XMLification might make sense, with DOM stuff and
> scripting etc, would be to replace the current "define a struct and then
> pass a pointer to a pair of big descriptive constant arrays" way of telling
> the Properties code how the object's data look like with an XML-based
> approach (keeping all behavioural stuff, ie selection, movement, updates, 
> drawing in the C file). But I'm not sure that would buy much: again, the
> problem of ease of access for the C side. However, one thing that could be
> _very_ nice would be to build a DOM tree out of the existing PropDescription 
> array. That would buy you DOM access on C objects which would still be defined 
> the exact way they are now (finally, we have a relatively non-redundant of
> telling the core what an object is). And _that_ would probably be a cool thing 
> for scriptability.


See? We agree...mostly, anyway. I would definately go further than you 
seem comfortable with in moving functionality to the XML side, but agree 
that things aren't that bad to begin with. Here's what I would love to 
see (and would be happy to help implement, given that I'm actually more 
familiar with DOM-like APIs than C structs):

1. Make all object type and properties declarations in XML, using a 
very, very simple schema-like language (basically the PropDescription 
transformed into XML). Optionally, include a snippet of SVG which 
describes the visual appearance of the object.

2. Internally represent diagrams as documents, and use DOM-style 
functions for basic traversal and manipulation. No more manually 
iterating over every layer, and every object in that layer -- just call 
xmlSaveFile("Untitled", diagram), and leave the driving to libxml.

3. Use DOM-style events/listeners (or a simulation thereof, using GTK 
signals/handlers) to trigger re-rendering, object update, etc. (In 
effect, the current view just listens for changes to the diagram, which 
in turn listens to changes in its layers, etc., etc.). For sciptability, 
this is a huge win: you don't have to expose any rendering 
functionality, you just provide bindings to manipulate basic object 
types within a diagram, and updates automatically cascade up the 
containment hierarchy.

 > Anyway, if you prove me wrong with working code (I've got a P133 to
 > check the speed side...), then alright, I would have been wrong  [:-)]

It should be at least two to three times faster than Netscape 4.X 
(simpler DOM, no JavaScript, faster parsers, etc.), so if that P133 can 
do any web browsing, I think we're okay. No, it's not going to compete 
with well-tuned single-purpose C code, but you should be able to 
maintain and extend the app in a fraction of the time it takes 
currently, as well as share more code and resources with other 
applications, since the design will be more familiar to new developers.

Anyway, feel free to send criticisms or ideas my way, and let me know if 
there's any interest in seeing this sort of migration take place; as 
I've said before, I'm using Dia for work in my office, and my employer 
is perfectly happy to let me bill them for time spent hacking on it. I'm 
moderately familiar with GTK, and fairly comfortable with XML and the 
DOM, so I'm ready to start working with anyone who knows the Dia core 
more intimately to make this happen.

Cheers,

Lennon Day-Reynolds
Software Engineer
Kestrel Institute
http://www.kestrel.edu