Re: *UserData Suggestion



On 28.03.2006 12:42, Athanasios Anastasiou wrote:
Hello All

After taking a look at the UML Objects i found it somewhat complicated.

You are not alone ;)

I love the way you describe the properties and mem offsets within the struct. I guess that the user interface is generated through the series of DEFINEs in the PropDescription structure.

This is only partially true. Especially the UML Class has all of it's user
interface written by hand.

However, i was just wondering why don't you use a Glib Dataset or a GLib Datalist to store the properties (under UserData). The properties need not have a particular type. These could just be strings and any code that needs them later can do the conversion.

I'm not sure if I understand your question so the answer may not fit (:

Dia's property system (aka. StdProps) has an extra indirection between the real Object properties and a set of properties. The latter gets passed around between the objects, the dialogs and the undo system.

As already noted elsewhere Dia's type system predates GObject so if you
are refering to UserData as in g_object_set_data() formerly known as gtk_object_set_user_data() that wasn't an option.

Also loosing the type information too early would e.g. not allow to generate type specific - but property agnostic - user interface, which is one of the main points of the StdProps system.

This will simplify the User Interface and the operations of getting and setting properties. In fact get and set operations will somewhat be taken care by the datalist. Interfacing the properties of each object with Python will also be easier this way.

If you think of writing
        # set object's name
        o.name = "New Name"
instead of
        o.properties["name"].value = "New Name"
that would certainly be possible with quite some extra code in the bindings layer. But for one it could be considered as syntactical sugar not worth the effort. And also it will introduce name space clashes between the objects properties and it's core attributes, example:

        o.type != o.properties["type"].value

Having the syntactical sugar would not make the dictionary based stuff obsolete - at least not if one wants more generic access as in export-object.py.

        Hans

-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to
get along without it.                -- Dilbert



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]