Re: Shapes layout proposal

[Lennon Day-Reynolds <lennon kestrel edu>]

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 
whatever) event


> 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
> implement though.
> 
> 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
> difficult.

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.

Agreed.


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


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 
hooks, etc.


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


Lennon Day-Reynolds
Software Engineer
Kestrel Institute