Re: Shapes layout proposal

[James Henstridge <james daa com au>]

On Thu, 14 Jun 2001, Cyrille Chepelov wrote:

> James,
>
> 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).

Note that the new XML shapes are based on this `classic API'.  I would
hope that we convert all diagram objects over to GObjects when we move to
gtk 2.0, along with the property code found there.  With a good set of
properties for an object, it doesn't matter that the structures are opaque
to the Dia core.

Hopefully properties will make it easy to have generic save/load code.
We already have some generic code for this with the current propeties
implementation, but in many cases, it doesn't quite duplicate the save
format of the current code.  At some point, we will probably have to break
some diagrams :(

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

Your generalised XML sheet code was a great improvement.

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

As well as switching over to GObjects for the diagram objects, I would
also like to see this switched over to GObject properties, which seem
like a more flexible system, and have support for default values
(which is something you were talking about adding to the current code
(which sounds like a good idea))

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

Well, making an object use the properties interface doesn't imply that the
properties dialog has to be handled via properties as well.  I don't
believe that generic properties dialogs will be sufficient for every
object in dia (and hand coding a property dialog for a few shapes may be
easier than having a complicated generic property dialog builder).  Other
people's opinions may differ :)

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

Another option is to make it easy to write new objects in a scripting
language.  Defining objects purely as data is not always appropriate.
Defining objects purely as code is not appropriate.  Maybe a hybrid
solution would be useful.  I don't know how easy this would be to
implement though.

This may lead to something similar to the old RenderStore method, except
that it could use the drawing code for custom shapes.  Writing an object
implementation in python might not be that bad, and if it did all its
drawing using the custom shape code (eg. load a number of shapes from XML
files, then render one here at this size, one here, etc), speed probably
won't be a problem.  The distance_from() method may cause some speed
problems with interpretted code though.

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

With these hybrid objects, where should the control rest?  Making it easy
to load and use shape descriptions from external sources (files) in other
objects might solve most of these problems.  Going the other way sounds
difficult.

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

Well, diagrams are really a tree of objects, and XML is good at
representing trees :)  The current format is not perfect, but it serves
the purpose well, and has been easy to extend.

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

By container library, do you mean what is used for the in memory
representation of the diagram?  If so, then my following comments apply.
If not, then they don't :)

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

After having used it for a few years, I don't find it that nauseating.
The new GObject stuff in glib 2.0 has a lot of features that fit Dia's
basic structure quite well.  Also, most of the gtk+ language bindings have
tools for generating bindings for GObjects (or will have once they are
ported over), which would help out with scriptability.

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

It isn't clear to me that the w3c DOM is a great model for Dia to use
internally for many of the reasons you state above.  Also, the DOM can
represent arbitrary XML files, which is more manipulation than makes
sense.  Our current scripting interfaces allow you to do most diagram
manipulations already.

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

I don't know STL, so won't comment on this much, other than to say that it
raises the bar for writing bindings for dia to allow scripting.

> 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

As I said earlier, I think it would be easier to allow C objects (and ones
written in scripting languages once the appropriate interfaces are bound)
to load shapes from XML files and use them for drawing, etc.

> 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

James.

-- 
Email: james daa com au
WWW:   http://www.daa.com.au/~james/