Re: Shapes layout proposal

[John Palmieri <johnp martianrock com>]

Ok well I'm just going to comment on the points I have some knowledge on. Comments are
inline:

"James K. Lowden" wrote:

> Recap
>
>
> There is some controversy over just how far the generic Shape property & behavior can
> be carried.  As James said, "hand coding a property dialog for a few shapes may be
> easier than having a complicated generic property dialog builder".  That's
> unquestionably true, for some value of "few" and "complicated".  Everyone agrees that
> identifiers and textboxes in Shapes would be a Good Thing.  (I look to GtkTable as a
> model for how they should be handled.)
>

I think tables are harder to work with than nested containers ala Gtk+'s vbox and hbox.  My
widgets.dtd reflects this.    I am not a GUI expert so I will digress on this issue and
leave it up to those with more experience.  A generic properties box ala Visual Basic's or
Borland tools prop boxs would be nice to have for quick and dirty objects (PhD theses.
lol.) but the option to turn them off for custom dialogs would be a must.  Again, not a GUI
expert.

>
> Some people are noodling about how shape behavior might be defined without C.  Could
> scripting be embedded in the shape definition, or next to it (in another module), for
> instance.  People seem open but skeptical.  Lars favors a better/simpler mating of C to
> Shapes, if anyone could figure out how to do that.
>

Binding C to shape would not be too complicated.  Having shapes load in .so files with a
standard interface for communication (bonobo or corba might work here though they might be
slow).  I've been working on SOMELib, a dynamic C++ class loader for some time now.
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.

>
> There was a brief conflagration over the in-memory representation of shape properties.
> DOM is seen as too text-based and thus slow for Dia, as well as contemplating
> still-undefined where-to-put-the-behavior questions.  STL has been bandied about as a
> desirable alternative, but no one feels ready to tackle it, and it's seen as part of an
> all-or-nothing C++ conversion.  (Not so, IMHO.  I have 10 years of C++ experience, most
> of it dragging inscrutable C applications into the modern age.  It can be done
> incrementally, and STL is your friend.)
>

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.

>
> What's on the table
>
> John describes what I'll call the "UrShape" (as in "prototypical shape") thus:
>
> > -Extend the SVG shapes with a new DTD for widgets and containers.
> > -Add the notion of ID's or named components to the Shape files
> > -Add a C interface for querying for ID's.
> >
> > -All C callbacks expect a pointer into the XML structure pointing to the node that
> > tripped the event.
> >
> > -Saved files would save out the whole Shape allowing other programs to load a dia
> > diagram with a simple filter.
>
> UrShapes will resize with their contained data, sensitive to text font, size, and
> quantity.
>
> My questions and comments
>
> I think it's implicit that UrShape behavior should be managed generically, just a is
> currently done for Shapes.  The UrShape handler has to allow for event interception by
> specialized shape-handler logic provided (presumably) by the UrShape author.  As James
> points out, there's a limit to how far such a generic interface can go without crossing
> some threshold of intolerable complexity.  Where that boundary lies depends on whose
> thumbs and thumbscrews are involved, and who's doing the turning.
>

Generically is the key word here.  Think generic functions in the STL.  One consistent way
of handling shapes and behavior is highly desirable.  Of course keeping things simple often
does clash with making things flexibility but not always.  By creating one interface and
handling things like resize and layout automatically we can vastly reduce the amount of
code needed to write a complex shape and they will all be consistent with each other.  We
can also offer incremental complexity levels via things like the generic prop box.  People
who want to code full blown dialogs can but those who do not want to can simply define
textboxes and let the generic prop box do the rest.  In C++ I can use generic functions to
do searches on containers, write my own (though it might be a bit more involved if I am not
used to writing generic functions) or go with what is comfortable and write for loops for
each container.

>
> I searched the my Dia-list archive for GObject discussions.  Are you talking about
> http://www.remotesensing.org/docs/gfc/docs/GObject.html and is that the best
> reference?  Everyone seems to think it's a good thing to use.  Is it just a question of
> when?
>

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.

>
> John, I disagree with your last point about saving the shape into the data file.  I
> think we should take a page out of the XML & SGML book: Shape definitions should each
> have a URL and be online from Dia or a Dia mirror.  They should be downloadable in part
> or in their entirety, or browsed/referenced in place.  This is a textbook example of
> something cheap to share and expensive to reproduce.  One online shape definition would
> save thousands of in-place copies.  Shapes are a resource to Dia as fonts are a
> resource to X; they should be findable and installable.
>

I wrote a paragraph disputing this point and in the process realized that saving whole
shapes would not be the best idea.  The option to do so (or embed the original shape
description) should be a part of Dia but should not be the default.

>
> I think the UrShape DTD should fit within SVG as much as possible.  That idea is
> consonant with having generically defined UrShape behavior as a superset of current
> Shape behavior. I don't understand DTD grammar well enough to know if John's widget.dtd
> does that.
>

I disagree here.  It should fit with but not within SVG because by doing so we would be
altering the SVG standard.  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.
This also allows for eternal programs to output SVG files that can be later dropped into a
Dia UrShape with no need for source level editing.  If we need to we can duplicate SVG
functionality within our own format (things such as grouping).

>
> SVG provides for aggregation, why not use it?
>
> Unfortunately, SVG doesn't define <table> as in GtkTable; all we've got is <text>.
> Furthermore, what I'm really looking for -- what I think everyone wants -- is
> user-defined properties.  Not blind text in tables, but meaningful self-desribing
> text: <name>, <id>, <phone>, <color>, <whatever>.
>

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).  One solution would be that any controls within an array container
serves as a template.  When a scripted event (return key pressed, button clicked, etc.)
causes the container to generate a new row of controls and their ID's are appended with an
incremented numeral.  The other solution would be to provide an interface to get a row from
the container and access the controls that way.

>
> What's the Right Way to go about providing for user-defined attributes, in XML/SVG
> terms?

I think SVG already has the notion of id's.

>
> Thank you for bearing with me.  I realize I'm not up to speed yet and I'm running the
> risk of taking up your time unnecessarily.  The whole long discussion has been very
> very helpful and interesting and I bet there are lurkers who are benefiting, too.  I
> hope my summaries and restatements are a contribution and not a drag.
>
> --jkl
>

James, I think you did a very good job of summarizing all the useful info that has been
discussed on this subject.  Keep the thoughts rolling in.

--J5