Re: Shapes layout proposal

["James K. Lowden" <jklowden speakeasy org>]

John,

I take the silence from everyone else to be anything this side of "are you nuts?"  That is,
they either agree or are taking a wait-and-see approach.  For now, we're in.  So let me firm
up where I think we're going, you and I, at least.

> I think tables are harder to work with than nested containers ala Gtk+'s vbox and hbox.  My
> widgets.dtd reflects this.

Gtk tables look good for what they do, and they're not mutually exclusive with aggregation
(what you're terming "nested containers").  I'd like to see support for them in the UrShape
DTD.

> Binding C to shape would not be too complicated.  Having shapes load in .so files with a
> standard interface for communication ... Loading in libraries and managing them takes some
> infrastructure work but it is not too involved.  This give us the advantage of not loading
> in code until it is needed.  This of course can all wait for other issues to be resolved
> first.

Right, OK.  I'd like to avoid most of this in the first pass.  Please keep in mind how much I
have to learn.  Behavior has to be overrideable -- or, specializable, if you prefer -- but
I want to start from the premise that Dia will handle any UrShape herself sensibly, somehow.

> I like the idea of a mini-DOM based representation specific to Dia.  I see the flaw with
> just using libxml.  God knows why they didn't place the ability for numeric data in the
> standard.

We need to focus some more attention on this.  Hand in hand with defining the DTD, we have to
define a C or C++ behavior interface.  Since I'm doing the talking at the moment, I'll use my
preferred terms: the shape is an object, and the object has properties and methods.  The
methods create behavior; the properties hold named attributes and the attributes hold data.

I'll next define such an object notionally in C++ for us, and then we can see how my idea of a
header file mates to your idea of a DTD.  That will have the merit of concreteness and will
win us either loud acclaim (!) or cat calls, eh?

Someone raised the notion of each component of the aggregated UrShape having its own
serialization capacity, to which I say: Yes, right on, brother.  It hints at another good
idea: each component of the UrShape ought to conform to a standard interface through which it
can be managed.  Serialization is only one example of such management.


> I like the idea of the GObject.  I am not too familiar with them but if they support  some
> sort of  OO the new UrShapes may be able to be encapsulated within them, overriding the
> props interface to be consistent with the other types of shapes it will coexist with.  I
> also like the idea of creating a mini-DOM interface for interacting with a tree of GObject
> nodes.