[no subject]

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