Re: *UserData Suggestion

[Hans Breuer <hans breuer org>]

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