I had some random comments about gobject's property mechanism, i'm not sure it's really worth pursuing, since i've got well-working workarounds in place, but food for thought...
For language-bindings, and similar purposes, it is often beneficial to bypass the gobject property mechanism: - it is a bit of a pain to implement a property-id allocation system, and then implement get_property()/set_property() appropriately. the problem grows worse if subclassing is considered. for other projects i've added a new property system with: my_object_class_add_property_full (MyObjectClass *class, GParamSpec *pspec, MyGetFunc get_func, MySetFunc set_func, gpointer data, MyDestroyNotify destroy_instance, GDestroyNotify destroy); the destroy_instance function is called from finalize, and provides e.g. string parameter the opportunity to free themselves. One can add additional macro gobbledegook to make a nice macro that adds an integer property to the class, using only the name of the object-type and the member-name. (It uses offsetof to figure out where the member to set is located) Same for essentially any other property type, though there are perhaps caveats. Many objects have to do special things when a property changes, and so such simple macro properties are useless; but other objects are factory-type objects, and simply need a member set. So, in one project i have: UF_OBJECT_CLASS_STRING_PROPERTY (object_class, MyObject, string_member_name, "string-member", "String Member", "The String Member", NULL, G_PARAM_READWRITE); and that takes care of the get_property(), set_property() and finalize(). It uses an inline function and hackery to ensure that string_member_name is a 'char*' (or at least warn if it isn't). it seems like it would be easy to graft this into gobject, i could provide patches pretty easily. - it would be nice if g_object_new() could fail... i really think that a system that supported property-setting to fail would be useful. in my systems, at least "MySetFunc" returns a gboolean with GError-style handling. But that may not be deemed acceptable for gobject. in any event, on the plus side, gobject has been totally flexible enough for my needs to introduce these things in a subclass, so that works nicely... just some random thoughts, dave _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list