Re: Shapes layout proposal

[John Palmieri <johnp martianrock com>]

James,

Ok, good we are on the right track now.  What I need from everyone is a short description on how
they want to help out in this effort so we can assign tasks and not duplicate each other work.  I
can basically manage this effort for right now - write the DTD's, assign tasks, code reviews,
documentation, etc.  When I finally network this house and get some connection to the net that my
Linux boxes can use then I can start messing with the code.

Well we need to start by seeing how we are going to approach the problem.  Are we going to write
without dia first and then integrate it into dia?  That necessitates a lot of wasted graphics work
although it might make it easier to work with in the long run. Ok comments inline:


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

I'll put it in.

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

Yes, my only problem with this is that properties are flat.  We need to define a way for the
properties to be OO.  For example if there is a property for a box called mybox, mybox should
return an object that conforms to the property interface.  That object should then have properties
of x,y,height,width.

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

I would like UML instead but give me the .h files and I will convert them to both UML and DTD's.
Hmm, more and more files are being edited, we need access to some sort of CVS server.  ALso, we
can't use C++ itself because Dia is written in C.

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

Agreed.  Hmm, "simple" might not be right.  I forget which project is working with SVG shapes in
GNOME for a illustration package but we should check out their parser.  Well at least it might be
nice in the future once we have the layout algorithms right.  For right now we will stick with
"simple" shapes but in the future I could see a use for complex vector graphics (a companies
logo?).

> 2.    Arrays.  Anything an UrShape can contain, it can hold in limitless quantities.

Agreed.

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

SVG calls these groups denoted by the <g> tag.  I think we should too.

> 4.    Tables.  Not just textboxes.  Too necessary to ignore, too easy to pass up.

Are you talking about table containers or tables as in a spreadsheet?

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

x, y, height, width.  These are default attributes which will have default behavior associated
with them (i.e. moving and resizing).

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

The interface - perhaps DOM like.

> 3.    Dia will be able to load any UrShape with any level of nested aggregation.

Yes.

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

This is why we should have an internal DOM representation.  Adding any object on the fly would be
easy - just insert the object in the right place on the tree.  Adding members to an array would
need to be scripted.  Default behaviors would be hard to define.

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

Ok, but I want to work on layout first.  The saving of data is the least of our worries and should
be easy once we have an internal structure.

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

Hmm, I think we put it on screen first.  Since getting data would be part of the scripting phase.
Writing dialog boxes to handle properties is a waist of time.

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

As long as we keep moving.  How old are your kids?  Perhaps they can help out on the hacking.
Hehe.

--J5