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.

>From my perspective, the library that gets the UrShape off the disk and into an instantiated
object is the object to use.  I'm still hoping 1) not to do this alone and 2) not to write the
I/O code.  The latter because I've done it so often it would feel like work (or sleep).  I
assume I won't be parsing the XML.  I assume some library will do that for me.

Will one of the elders please tell me, Did I find the right GObject and is there any reason
not to use it for what we're doing here?

> > John, I disagree with your last point about saving the shape into the data file.

> The option to do so (or embed the original shape description) should be a part of Dia but
> should not be the default.

Once we get off the ground, OK.  I'm not convinced, but I don't have to be, especially if I'm
not doing the I/O.

> > I think the UrShape DTD should fit within SVG as much as possible.

> By encapsulating SVG within our own format (as it is done within the shapes.dtd and
> widget.dtd) SVG is preserved.  This allows us to use outside SVG
> parsers if need be.  When SVG blocks are encountered they can be passed to an SVG parser.

Understood, accepted.

> By giving a textbox or any control an id (<textbox id="mytextbox">) we do define a
> property.  In this case property "mytextbox"  which will have member functions such as
> getText() when scripting and/or C bindings is implemented.  One issue that will have to be
> worked out is containers that have an array of controls (i.e. UML shapes where there are an
> array of properties).

Understood.

+++

The next thing you'll see from me (besides vacuous witless arguments) is a .h file declaring
an UrShape class.  It will have the following qualities:

1.    Nesting.  An UrShape can be nested in another UrShape.  UrShapes can constain "simple"
SVG shapes, too.
2.    Arrays.  Anything an UrShape can contain, it can hold in limitless quantities.
3.    Pages, a/k/a layers.  That is, something akin to property pages, for UrShapes that don't
want to display all their members at once.
4.    Tables.  Not just textboxes.  Too necessary to ignore, too easy to pass up.

In case it's not obvious, and because stating the obvious is both easy and frequently a good
idea, let me state the obvious.

1.    The UrShape has no predefined attributes beyond the capacity to acquire them from its
XML definition.
2.    It has well-defined methods for making it behave (whipping, abuse, sarcasm, bullying,
humiliation, etc.  Oh.  Sorry.  This isn't the Python list?)  and predefined collections that
hold its run-time defined attributes.
3.    Dia will be able to load any UrShape with any level of nested aggregation.
4.    The generic UrShape handler will be able to render the UrShape on the screen, and will
allow the user to edit data associated with any attribute.  "Editing the data" includes adding
members to arrays.  If I get very ambitious, it also means adding attributes on the fly (that
would be fun).

The logical step from there would be a standalone (non-Dia) prototype to work out the I/O and
dynamic attribute dialog.  All the prototype would do is load an UrShape into memory, open a
dialog box to edit the data, and save the new data.

Then we can put it, as Captain Kirk used to say, on screen.  In Dia.

One cautionary note.  This is not going to happen at warp speed.  I have kids and a life and
vacation in August.  I'm aiming for as little wasted motion as possible, of necessity, and
something useful by Christmas.  I wouldn't anyone thinking we should hold up .90 for my
castles in the sky, you see (not that I was worried).

I'm being definite with a purpose.  I figure if I'm out of line the Dia boot camp, er,
community will put me back in line and give me my teeth back.

How's that sound to you, John?  Lennon, Andre: you interested?

--jkl