Re: *UserData Suggestion

[Athanasios Anastasiou <thanos atmail com>]

Hello Guys

Thanks for answering my post, please see below

@Hans Breuer

> 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 (:
Yeah, but maybe i contributed to this confusion a bit :-)

> 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.
I am trying to unweave the code to understand this land called Dia and how i can move within it :-). The 
property system was not THAT obvious :-)

> 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.
No, i am not referring to *Userdata as a widget's *Userdata pointer.
The application needs a way to represent nodes and to be able to extend those objects with minimal impact on 
the main codebase.
I think that the way it achieves this is by offering a generic Node object which has plain properties such as 
color or whether or not background is visible and so on. The way to extend this basic object is by allowing 
the programmers of external objects to add their own properties (in the form of structures) in this generic 
Node object. I was looking for this at some point and i think that the field is called Userdata. The 
application needs also a way to access this void *Userdata and it has no information about it (since you want 
to preserve the type). Therefore you end up with this complex system of describing the properties using all 
these functions. Afterwards it is very easy for a widget to copy its content to a memory location+offset 
since all this information is now known.
So having seen all this, i was wondering why don't you use a simple mapping between property names and 
values, as you can read in a previous post of mine.


> 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.
I agree on this one but then it really depends on what level of information is needed. You can also describe 
the types as strings. That's just a suggestion ofcourse.


All the best
thanOS