Re: libglade custom properties

[Paolo Molaro <lupus ximian com>]

On 11/23/01 James Henstridge wrote:
> >>Note that this API addition is a "semi public" API -- a normal app 
> >>wouldn't use it, but a library implementing libglade support may need it.
> >>
> >
> >What if a library of widgets written in some language binding
> >needs to have custom property support as well?
> >You need the usual user_data/destroy_notify pair in the API.
> >
> Assuming all widgets were fully customisable through the normal 
> properties interface, then this API shouldn't be needed...  Note that 

But if it's needed, why should it be restricted to C?
Can you anticipate that it will not be needed by language bindings?
Yes, most of the time a binding can use (different) workarounds,
but why should we make it difficult to do so?
Besides a user_data argument can be handy when coding in C, too.

> the other APIs for registering widget build and child adding routines 
> also have this defficiency, so I don't know how useful it would be to 
> fix this one problem though.

So, that APIs needs fixing, too :-)

> Note that if your custom widget, written in some language binding, 
> supports the standard properties interfaces (widget properties and if it 
> is a container, child packing properties), then no special libglade 
> support will be necessary at all.
> 
> Does this sound like it would be enough for your perl bindings? (I think 
> it should be enough for the python bindings).

I can't anticipate what will be enough for a language binding, I just
want to be able to do the same things I can do in C :-) (specially if
supporting it is just a user_data argument away).

> Note also that these handlers would never be freed, so a destroy notify 
> wouldn't be used even if I added it as an argument.

Ok, the user_data argument is enough, then.

lupus

-- 
-----------------------------------------------------------------
lupus debian org                                     debian/rules
lupus ximian com                             Monkeys do it better