Re: Shapes layout proposal

[Cyrille Chepelov <chepelov calixo net>]

Le ven, jun 15, 2001, à 01:05:29 +0800, James Henstridge a écrit:

> Hopefully properties will make it easy to have generic save/load code.
> We already have some generic code for this with the current propeties
> implementation, but in many cases, it doesn't quite duplicate the save
> format of the current code.  At some point, we will probably have to break
> some diagrams :(

Actually, this code has been in use for some time, now. And all formerly
lazyprop objects use them, and are fully compatible with older diagrams.
This won't be that easy for some diagrams, though: we'll certainly have to
use the version field one day. But I'm confident that won't be much more than
keeping the object's old load routine around (anyway, even pure StdProp
objects have their object_load routine called ; they have to manually call
object_load_using_properties() if they're lazy. Otherwise, they can still do
their stuff).

Bringing as many objects as possible to pure StdProp (that includes
load/save) is high on my list, shortly after UTF8/libxml2.

> > One way I think of, to convert "classic" objects such as (in particular)
> > "UML - Class" (the reference hairball), would be to slightly extend the
> > StdProp code so that callbacks could be bound whenever a property widget has
> > been touched. Of course, I plan to add "button" property types (in the vein
> > of the recent PROP_TYPE_NOTEBOOK_* and friends), which would help. This will
> > require to split object_create_props_dialog into object_create_props_dialog
> > (creates the dialog, with the widgets) and object_fill_dialog_with_props
> > (sets the widgets of the dialog with the values from the object), and other
> > quite minor changes.
> 
> 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 :)

I'll show code before I bring the issue back. What I've got in the head
looks nice <grin/>, but it has to be committed to C to resolve a few unknowns.

What do you think of my recent additions to lib/properties.[ch] ?

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

I sense mozillaisms here... (yes, distance_from(). However, if we've got an
SVG-like [preferably in object/custom's internal representation] view of the
appearance of the object, distance_from could probably be written as C
code).

> > One recent proposition has been "let's write the schema in XML and add C
> > bindings for behaviour" (ie, replace the PropertyDescriptor structure with
> > XML stuff, mess with an unknown mean of binding the aforementioned XML stuff
> > with the C behaviour functions [I sense something quite close to the
> > PropertyOffsets array]). Well, we might as well use Express-G (ISO 10303),
> > an RFC 822-like format or even the Python pickle format to replace this
> > description ; I still think the way property descriptors are currently
> > written is the most efficient way, both machine-wise and developer-wise (One
> > object == one single file, except when the dialog box becomes so big it
> > makes sense to delegate that code in a separate file. And even that could
> > (will) be improved).
> 
> 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.

The problem is, we're then going to define an object as an inter-related set
of files ; I'm afraid this will lead to brittle code.

> > Part C)
> >
> > Now, what this discussion brought forward is a really different matter: it's
> > a matter of what should be the standard container library. To simplify
> > things, there are three choices:
> 
> By container library, do you mean what is used for the in memory
> representation of the diagram?  If so, then my following comments apply.

precisely. While doing the draft for this post in the train, I did mention
"in-memory representation", just forgot to copy it over....

> > 	* glib+custom C stuff (this is how things are done). Frankly, glib
> > code gives me nausea from time to time. It may be compact and efficient, but
> > it requires lots of casts and/or lots of accessor macros. It's ugly. But it
> > works, and it's rather efficient, down to the machine.
> 
> 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.

Well, after a while the nausea feeling begins to fade, as one gets used to
it <grin/>. 


> > 	* DOM: this is the recent proposal. Basically, instead of having a
> > machine-optimised representation of data (structs and pointers to structs)
> > and having a translation layer when doing reads and writes (the reads doing
> > a whole conversion of XML data into a machine- (and C developer-)optimised
> > representation), we have a big tree in a big library (which some developers
> > do know very well), which mostly stores bits of strings and type identifiers
> > on these bits of strings. But for the average C object, this'll be a
> > nightmare to access data: what's the most efficient to store a point's
> > coordinates ? a pair of floats or re-parsing the result of
> > sprintf(buf,"%f,%f",x,y), after some incantations to a big library to
> > locate, find and finally fetch the data you're looking for (and this, to
> > each foo_draw() call, unless some yet to be specified cache layer is to be
> > used).
> 
> 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.



> > 	* STL (several core and casual developers have been heard moaning
> > about how cool it would be to have "real" containers. Myself included).
> > Requires a full rewrite to C++. 'nuff said.
> 
> I don't know STL, so won't comment on this much, other than to say that it
> raises the bar for writing bindings for dia to allow scripting.

yep. I mentioned it, because it gets called back every so often, but it's
really not an option at this point. For new work, it is cool, though.


> > So, to summarise my position: the current shape format can, and should
> > probably be extended to make more dynamic stuff. Aggregate shapes look cool,
> > dynamic aggregate shapes look even cooler. None of this looks like a
> > candidate for the "waaaay tooo slooooow" prize, quite the contrary. I'm
> > extremely sceptical about the practical feasibility of optionally adding C
> > bindings to add more dynamic behaviour to shapes (and have that C code easily
> 
> 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.

.... one variant is to make easy for C objects to aggregate any kind of
object (including of course shapes). Or, for simpler cases, allow a
shape-like definition of aggregates.

Where are we on the .89 front ? 

	-- Cyrille

-- 
Grumpf.