Re: Expanding the Shapes dtd

[John Palmieri <johnp martianrock com>]

Ok, well I sent this reply to the list as well as to you James.  We should keep the
discussion there so people can be free to comment or ignore us as we go along.

I can't code much now because I have no real access to CVS (Just graduated and am
relegated to using my parents AOL connection until I get a job, which is proving
very hard).  I can however write the DTD's and some sample code.  Our first job
would be to figure out all this layout stuff.  I was looking through some SVG
documentation and found mention of containers but when I looked closer it was a
dead end.  SVG has a way to do transformations of viewports but that is only useful
for scaling objects within a container not for scaling the container based on the
objects within it.  What I propose is to not mess with the shape.dtd but instead
create a widgetset.dtd.  Tables for layout won't work since they are messy to code
and don't take into account overlapping items.  Instead we could use containers and
linked shapes.  Containers would hold widgets and grow in the y2,x2 direction with
the widgets.  Shapes outside the container are automatically translated to new
positions and their y2,x2 can be linked to the containers or another shape with the
linkto(ID, x1 | x2 | y1 | y2) directive.  Only containers can propagate resize
events.  If a container changes another container the second container again
propagates a resize event.  To prevent an infinite loop a container can only be
resized once per session.  A session is defined as the time it takes for the
initial resize event to propagate through all the shapes.  e.g. in sudocode:

#This is one session
start resize on container ID="square1"
     resize shape ID="linesegment"
     resize container ID="square2"
     start resize on container ID="square2"
          resize container ID="square1" - already been resized
          resize shape ID="linesegment"
     end resize ID="square2"
end resize ID="square1"
#end of session

I hope that makes some sense.  There are some holes in my logic that need to be
ironed out. Once we get layout working we can work on scripting.  I prefer Python
myself.  What widgets would be good to include?  I was also looking at the xlink
stuff.  Using xlink we can create hyperlinks to other dia documents, web pages and
even other GNOME apps.  What do you think?

-J5

"James K. Lowden" wrote:

> > I think right now we need a big discussion on what can be done. I would be
> > most helpful on the
> > XML and scripting hooks stuff.  If only one of the GUI guys would be
> > interested enough.  As I see it the hardest part is the layout.  It would
> > have to be simple.  Nothing like GTK's complex system.  HTML tables come to
> > mind but they are a disaster to code.  Perhaps a simple version of GTK's
> > hbox and vbox stuff.
> > I'll have to study up on SVG in more depth.  Perhaps this layout issue has
> > already been resolved within the specs.
>
> John,
>
> Funnily enough, I'm encouraged by your answer.  You're focussed on what I think
> is a crucial missing part of Dia, and you're qualified to design a solution.
> Even though you didn't get a response from the list :( I think I see a way
> home, if you're patient.
>
> When I first contacted the Dia developers several months ago, the list was
> practically silent, nothing like the traffic we see now.  I mailed the list,
> James Henstridge, and finally the FSF before anyone said "boo".  James' basic
> recommendation was to "go to it"; if I could make a better widget, he'd be
> happy to see it.  That was in, oh, Feburary, I guess.
>
> Since then, I've set up a Linux box (twice, settling on Debian) so I can build
> the current release.  I read the GTK manual, read and read and read about XML,
> and sort of thrashed around figuring out where to begin.  It's a lot to master
> and I don't have much to show for it, but I'm much further along than I was.
>
> Here's what I propose:
>
> I'll be your GUI guy for your new/better XML/SVG DTD(s).  I share your x,y
> sentiments and I haven't written code like that in 10 years, but it's what
> needs doing, and I think I can duck most of the tedious display issues.
>
> My immediate objective is a proof-of-concept, a "soft shape" whose properties
> are defined (within limits) in the SVG file, and whose on-screen dimensions
> vary with the data.  My direction is a shape that can hold logical and physical
> modeling data for a relational database.
>
> I know HTML and sgml tables, and I imagine XML has tables not too far away from
> them, conceptually.  I wonder if there shouldn't be some sort of XLST that
> would hold formating rules for an ordinary XML table?  In its absence, the
> shape could use some (fairly dumb) heuristic to lay out the table (and/or other
> properties).
>
> Clearly, you should design the DTD, since that's what you know.  If you're
> familiar with libxml2 or want to be, we'd get done faster if we defined an
> API layer atop it, that would slurp in a shape and populate a data structure
> describing it (and any formating information).  I'd work from there to the GUI,
> and you could work from there to libxml2 as need be.  If you don't want to
> code, that's OK, too, of course.  I'd be grateful for a good XML platform to
> work from and a resource I could call on with questions or issues.
>
> I wouldn't spring anything on the active Dia developers.  I'd tell them what
> we're working on and ask for comments.  I'd expect a bunch of attaboys mostly,
> except that the DTD issue might be sensitive.  But useful extensions get
> incorporated all the time, and the discussion is rational and apolitical.  If
> we have running code, I'm sure we'd find rough consensus.
>
> How's that sound to you?
>
> --jkl