Re: Shapes layout proposal

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

Cyrille, James, Lars, Lennon, John, Andre, all

One of the difficulties faced by anyone approaching a new project is understanding its
technical design.  In need of a top-down document that says "Here is the problem,
here's how we went about attacking it, here're the pieces and how they behave", one
more often finds "Here's a FAQ and the source code, have fun."  Learning a design by
reading source code is like reading a novel backwards.

For this reason, I'm grateful to Cyrille and the others who illuminated for me the "the
evolution of 'how to write objects'".  Very useful, occassionally awesome.  Thank you
for taking the time.  My original mail to John refered to defining some sort of
interface between the shape data and the rendering of it.  Cyrille, your epistle showed
me that Dia has confronted that task at least 5 times.  I should think the Dia
Documentation team found it helpful, too.

Those of  you who know what you're talking about undoubtedly could read and respond in
one breath.  I for one had to digest what was said and try to synthesize it.  I'd like
to review a few points and ask a couple of questions to make sure, as the argot has it,
that we're on the same page.  I hope, Cyrille, I'm not wasting *your* bandwidth.

Recap

There have been 5 strategies to creating/managing "stuff that the user can put in a
diagram", some ore successful than others.  The Classic system is being supplanted by
StdProps, and Shapes have been wildly popular, measured in variety of shapes.  There is
broad agreement that StdProps is the right way -- or at least best way so far -- to
handle complex shape behavior, and there is agreement that SVG Shapes can be made
richer and more functional.  There is some discomfort with the C/SVG dichotomy,
although it seems inevitable.

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

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.

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

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.

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?

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

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

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

GtkTable needs very little layout information: an origin, a number of rows and columns,
and spacing/padding rules.  Cf.
http://developer.gnome.org/doc/GGAD/sec-containers.html#FL-GTKTABLE.
I don't think we have to be any more explicit in our DTD.  Comments?

+++

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