GNOME.org
 

Re: Shapes layout proposal

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.
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]