Re: Shapes layout proposal
- From: Lennon Day-Reynolds <lennon kestrel edu>
- To: dia-list gnome org
- Subject: Re: Shapes layout proposal
- Date: Fri, 15 Jun 2001 11:41:15 -0700
James Henstridge wrote:
As well as switching over to GObjects for the diagram objects, I would
also like to see this switched over to GObject properties, which seem
like a more flexible system, and have support for default values
(which is something you were talking about adding to the current code
(which sounds like a good idea))
Sounds reasonable; any clues as to when GTK/glib 2.0 is going to be
declared stable? I'd like to start working with GObject, but haven't
made it a priority, because none of the working code I have uses it...
Well, making an object use the properties interface doesn't imply that the
properties dialog has to be handled via properties as well. I don't
believe that generic properties dialogs will be sufficient for every
object in dia (and hand coding a property dialog for a few shapes may be
easier than having a complicated generic property dialog builder). Other
people's opinions may differ :)
Hint: Generic event handlers, with the built-in properties dialog code
simply being the default handler for the normal double-click (or
Another option is to make it easy to write new objects in a scripting
language. Defining objects purely as data is not always appropriate.
Defining objects purely as code is not appropriate. Maybe a hybrid
solution would be useful. I don't know how easy this would be to
This may lead to something similar to the old RenderStore method, except
that it could use the drawing code for custom shapes. Writing an object
implementation in python might not be that bad, and if it did all its
drawing using the custom shape code (eg. load a number of shapes from XML
files, then render one here at this size, one here, etc), speed probably
won't be a problem. The distance_from() method may cause some speed
problems with interpretted code though.
Hallelujah! That's exactly what I'm hoping for -- XML definitions of the
basic properties and rendering style for an object, and access from C or
a scripting language to the named properties within that SVG (hence, my
interest in the DOM).
With these hybrid objects, where should the control rest? Making it easy
to load and use shape descriptions from external sources (files) in other
objects might solve most of these problems. Going the other way sounds
See comment above about allowing runtime registration of event handlers
from both C and scripting languages.
Well, diagrams are really a tree of objects, and XML is good at
representing trees :) The current format is not perfect, but it serves
the purpose well, and has been easy to extend.
After having used it for a few years, I don't find it that nauseating.
The new GObject stuff in glib 2.0 has a lot of features that fit Dia's
basic structure quite well. Also, most of the gtk+ language bindings have
tools for generating bindings for GObjects (or will have once they are
ported over), which would help out with scriptability.
I'm not active on any of the gtk/glib scripting language binding groups,
so I'm not sure how much activity there has been on supporting 2.0, but
from what I've seen of the preliminary API documentation, it's not going
to be an easy task. The new GObject implmentation has (to my inexpert
eyes, anyway) most of the semantic richness of a fully object-oriented
language, along with a few quirks to accomodate its implementation in C.
It isn't clear to me that the w3c DOM is a great model for Dia to use
internally for many of the reasons you state above. Also, the DOM can
represent arbitrary XML files, which is more manipulation than makes
sense. Our current scripting interfaces allow you to do most diagram
I think my comments about the DOM were somewhat overblown -- both due to
my eagerness to press the point, and due to the (entirely
understandable) idiological resistance offered by other posters. You're
quite right that using a full DOM Level 2 or 3 implmentation would be
overkill; I was trying to say that using an internal API *based* on the
DOM would be a useful way to standardize interfaces, simplify scripting
As I said earlier, I think it would be easier to allow C objects (and ones
written in scripting languages once the appropriate interfaces are bound)
to load shapes from XML files and use them for drawing, etc.
I want to clear up a few things about the DOM, and why I was pushing its
use so enthusiastically. First of all, the core XML/HTML DOM spec
doesn't have support for data types aside from DOM nodes and Unicode
text; this is indeed a problem when the majority of the data you're
pushing around is numerical, as in a graphic application like Dia.
That's why there are different DOM interfaces for different XML
dialects, such as SVG. If you look at the IDL for the SVG DOM, it
support typed objects such as coordinates, time intervals, and links,
and it is expected that an implementation will continue to use those
typed interfaces up until the point where it uses an off-the-shelf XML
parser/writer to do file I/O.
Since everything is going into some sort of textual form eventually, of
course there has to be a way to manipulate property values as text;
right now, that's simply accomplished with formatted printing in the Dia
XML handling code; if you take the DOM/IDL/OO approach, though, each
property type would have an associated method or function which would
serialize it as a string, and read it back from one.
This all fits in fairly well with the GObject polymorphic value types,
with the exception of the automatic serialization support. I'm sure
that's being handled somewhere, and I'm just not glib-savvy enough to
find it. I imagine that XML data binding will be high on the list of
priorities, once the API has stabilized.
I'm looking forward to working with GTK 2.0 -- it reminds me of Java,
without some of the brain-damaged language limitations.
] [Thread Prev