Re: Shapes layout proposal

[Cyrille Chepelov <chepelov calixo net>]

James, 

   sorry for the slightly late answer ; as Nemo will tell you tomorrow
9:30am (my time), while I've had enjoyed almost two weeks with plenty of free 
time, there are times where real work has to be done <grin/>. What's good is
that in the mean-time, things have cooled and look technically much cooler
now (pun intended).

Before I begin, let me warn you that Google's database is littered with dumb
statements I made to this or that list, and I'm really fortunate that it
doesn't index the Fidonet forums... so, take this with a grain of salt; I
might say blue today and think red in two months (I'll just won't buy a Mac
in two months, *that* is certain).

Part A) I'll begin by summarising the various kind of objects we had in this
project ; the evolution of "how to write objects" is IMO interesting and
pretty much explains what I think about the project.

We have had no less than five different ways of writing "stuff that the user
can put in a diagram" (in roughly chronological order, the ChangeLog will
give you the historic details):
	1) "classic" objects: the original ones, as Alex Larsson had written
them. This is where everything started ! These objects had a problem,
though: they could be made to do just anything, and actually had to do
everything : XML code, GTK code, but actual rendering was already done
through the Renderer interface (which hasn't significantly changed since).
One marking thing was that classic objects were almost totally opaque to the
core of dia (except the ancestor struct, there was nothing the core could do
to know this or that element of an object's state).

	2) RenderObjects. Basically, they were a big C array which described
how to draw them. Library code handled everything, and of course these
objects were static (actually, much more static than the SVG shapes. Check
Sybase objects in 0.88.1 for the last glimpse, as they've been recently
killed (at last !))
	3) Shapes. That is, objects defined in an XML language, with the
graphical aspect defined in a subset of SVG (this is James Henstridge's
work, almost 2 years ago).

This is the state of 0.81 ; sheets are still static C arrays (even for
shapes). 0.82 brought sheets defined in an XML langage too. Shapes+Sheets
(in XML) really brought the explosion of sheets and shapes we have now,
relative to the four sheets we had in 0.81. [ I may have some facts in the
wrong order ; please check the ChangeLog for accurate stuff ]

	4) "Lazyprop" objects. I had some free time, wanted some objects to
handle diagram types I needed at work, shapes weren't dynamic enough, and I
was discontent with the amount of redundant code classic object required. So
I whipped together ugly macros, and wrote some objects with them (with one
exception, I was the only one to use lazyprops, fortunately). James H.
wasn't (rightly so) satisfied with the way lazyprops worked, and wrote
support for:
	
	5) "StdProp" objects. Basically, most load/save/copy/edit operations of
the "classic" objects are delegated to library routines, which work because
now objects are required to describe their schema through a pair of C
structs (one which describes the properties' names, types and human
description, and one which tells the core how and where to interact with the
property itself).
	StdProp are in fact relatively easy to write: to write one, you need
to know:
	- struct RendererOps;
	- properties.h
	- the ancestor object's interface (Connection, Element, OrthConn,
etc.)
	- glib (more on this later).

	Currently, RenderObjects have been killed (the code is still here,
but is not compiled anymore and will be deleted as soon as .89 is out,
unless someone objects) and replaced with shapes. Lazyprops objects have been 
killed altogether. A lot of objects are halfway between classic and pure
StdProp (Lars Clausen in particular has put a lot of work into that), some
objects are now pure StdProp.

[Lots of people have contributed to the above code ; I mentioned a few names
but this is really doing injustice to the others. ]

One way I think of, to convert "classic" objects such as (in particular)
"UML - Class" (the reference hairball), would be to slightly extend the
StdProp code so that callbacks could be bound whenever a property widget has
been touched. Of course, I plan to add "button" property types (in the vein
of the recent PROP_TYPE_NOTEBOOK_* and friends), which would help. This will
require to split object_create_props_dialog into object_create_props_dialog
(creates the dialog, with the widgets) and object_fill_dialog_with_props
(sets the widgets of the dialog with the values from the object), and other
quite minor changes.

Basically, you can see that the primary dynamic in the evolutions of "how to
write objects" is "make them simpler to write to the casual object user". We
do have a very strong dichotomy between static shapes on one side, and
dynamic StdProp objects on the other ; this is not very satisfying. Indeed,
the "aggregate shape" proposition looks really nice ; I'm still wondering
how to build an aggregate shape where some parts could be repeated a
user-specifiable and dynamic number of times, and I definitely think this
would be cool to see (and I surely don't think that would be significantly
slower than plain Shapes, which are currently of a very acceptable speed).

One recent proposition has been "let's write the schema in XML and add C
bindings for behaviour" (ie, replace the PropertyDescriptor structure with 
XML stuff, mess with an unknown mean of binding the aforementioned XML stuff
with the C behaviour functions [I sense something quite close to the
PropertyOffsets array]). Well, we might as well use Express-G (ISO 10303),
an RFC 822-like format or even the Python pickle format to replace this
description ; I still think the way property descriptors are currently
written is the most efficient way, both machine-wise and developer-wise (One
object == one single file, except when the dialog box becomes so big it
makes sense to delegate that code in a separate file. And even that could
(will) be improved).

Part B) file format

There is a general consensus that having and XML file format is cool.
Indeed, it has helped various "satellite" utilities to be written and do
cool stuff around dia diagrams. So, yes, definitely, XML is good. For
on-disk structures, certainly.

Part C)

Now, what this discussion brought forward is a really different matter: it's
a matter of what should be the standard container library. To simplify
things, there are three choices:
	* glib+custom C stuff (this is how things are done). Frankly, glib
code gives me nausea from time to time. It may be compact and efficient, but
it requires lots of casts and/or lots of accessor macros. It's ugly. But it
works, and it's rather efficient, down to the machine.

	* DOM: this is the recent proposal. Basically, instead of having a
machine-optimised representation of data (structs and pointers to structs)
and having a translation layer when doing reads and writes (the reads doing
a whole conversion of XML data into a machine- (and C developer-)optimised
representation), we have a big tree in a big library (which some developers
do know very well), which mostly stores bits of strings and type identifiers
on these bits of strings. But for the average C object, this'll be a
nightmare to access data: what's the most efficient to store a point's
coordinates ? a pair of floats or re-parsing the result of 
sprintf(buf,"%f,%f",x,y), after some incantations to a big library to
locate, find and finally fetch the data you're looking for (and this, to
each foo_draw() call, unless some yet to be specified cache layer is to be
used).
	
	* STL (several core and casual developers have been heard moaning
about how cool it would be to have "real" containers. Myself included).
Requires a full rewrite to C++. 'nuff said.

So, to summarise my position: the current shape format can, and should
probably be extended to make more dynamic stuff. Aggregate shapes look cool,
dynamic aggregate shapes look even cooler. None of this looks like a
candidate for the "waaaay tooo slooooow" prize, quite the contrary. I'm 
extremely sceptical about the practical feasibility of optionally adding C 
bindings to add more dynamic behaviour to shapes (and have that C code easily 
access the properties ; though this'll probably be less of an issue, since I 
assume the standard shape code will still be in charge of drawing, selection 
etc): basically, if you need really dynamic behaviour and hairball,
yet-to-be thought of objects, I think you should write C code (actually,
derive from a similar enough existing pure StdProp object, and hack from
there). What I'm really wary of, is objects which use libxml (or another DOM
library) as their core container library. This may be good for a data storage
and processing application, or mostly text-oriented applications in general,
but I really think dia's core isn't on the right side of XML's practical
application boundary. <troll>Otherwise, 
we'll see another guy pop up in a year or two and say "hey, this DOM-only
application sucks. Let's rewrite dia as a SVG parser-renderer, and use 
libfooXSLT to handle drawing as a transformation from diagram to SVG. Look, 
it's a simple 
	pipeMyStuffThroughXSLT(inXML,outXML,thatXSLTsheet);
call</troll> (okay, I'm really ignorant about XSLT ; I know it has a lot of coolness
points, but "real-time efficiency" is not the first word which I'd associate
with it. Strictly word of mouth, not technical/scientific reasoning,
though).
	
OTOH, the object interface allows very easily to write a parallel core to
StdProp (that's the way Custom Objects/Shapes work, after all). So, if
people want to have fun (why not on this list, after all ? Until the traffic
becomes too much, it's not a problem IMO, and it'll both fun and educational
to watch. Working on dia has already tremendously helped me improve my
skillset, and I'll watch DOM experiments with interest -- but probably watch
only), there's nothing to stop them (and if the experiment is successful --
well, that'll be really good. But I don't think C StdProp objects are going
away anytime soon, at least just because we don't even have enough
janitorial manpower to bring all current C objects to modern standards).

	I hope these mumblings and semi-rants weren't too much noise and had
enough signal to warrant the bandwith...

		-- Cyrille





-- 
Grumpf.