Re: Shapes layout proposal

[Cyrille Chepelov <chepelov calixo net>]

Le mer, jun 13, 2001, à 12:14:26 -0700, Lennon Day-Reynolds a écrit:

> 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:

[snip] yep. Okay. Now please show me the accessors from the C code (ie, show
me decent C bindings. And I really challenge you to show me more efficient
(source-wise) bindings than access to a struct member.

I definitely am on a close wavelength with Lars on this subject ; with a
slightly different spin: if you show me a shiny new dia core, with DOM as
its kernel, and the resulting stuff is not only as featureful (including all
current object types) as the "classic" dia of then, but also naturally is
able to reload older files (though it might be through an incomplete
translation layer), and all that with decent speed on my 32-MB P133, then I 
shall bow, eat my words, and adapt. 

Until then, I'll continue working with the current code base.

> 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.

You'd find if you looked at recently touched objects that modern StdProp
code is practically as compact as this. >And< the binding (for non-trivial
object methods such as foo_draw()) is the most straightforward one. Sure,
the property descriptors *could* be rewritten in an XML dialect (and with
the most recent additions, it sure looks like it could benefit from this),
but you'd make the actual writing of objects much more complicated: write
the (XML) schema. Write the descriptors (XML). Write behaviour (C). Bind
stuff together. Aaaargh. (oh, did I mention "handle every single datatype as
linked lists of C strings, regardless of what's inside" ? That might be good
for text-based stuff, but even fully DOM-based handling of SVG is a little of 
a stretch in my book. What object/custom does is much saner: slurp the stuff
into an efficient format (for the machine)).

As you slightly mis-read my position on the standard(s) for describing
properties, let me clarify what I think is current: James' Standard Properties
code is _the_ current standard for describing the properties of an object. 
It's pretty compact and clear. One older standard (lazyprops) has just been 
eradicated. Older objects still await upgrading to stdprop. But StdProp _is_ 
the standard (maybe until displaced by something more efficient, but I doubt 
this'll happen anytime soon).

As you mentioned interest, I surely would be interested in the results of
such a DOMification, at least for the educational and scientific value
(running code or failure to provide thereof will surely help solving the 
quarrel). I won't invest much more joules in that code and that discussion 
(until I'm convinced to do otherwise), I think my position, prejudices and 
beliefs on that particular project is pretty clear. OTOH, there's a growing 
list of semi-urgent enhancement bugs in the bugzilla (and not everything is 
reported yet. The biggest unwritten one being "write unit tests
everywhere"). I'll concentrate on those bugs for the moment (and on a few 
objects I think could be fun and quite useful).

        -- Cyrille

-- 
Grumpf.