Re: Gtk::Container child properties


I’ve just started working on this. I think we would need to provide a similar API for child properties as for 
other properties, because I don’t think all GtkContainer (maybe not even one) expose child properties through 
regular methods.

I see a major problem in doing this and I can’t find a valid approach that does not imply reimplementing a 
lot of things; maybe you could help me. The point is child properties are only available in Gtk+/gtkmm, while 
most of the infrastructure for generating code belongs to glibmm, and we don’t want to make glibmm depend on 
Gtk+ I think.

First, we would need to make child properties appear in gtk_signals.defs or other .defs file. That could be 
done more or less easily creating an additional get_defs in gtkmm.

Second, we would need to extend gmmproc to handle child properties. I see here a major problem. I’m not sure 
we could use the same _WRAP_PROPERTY / _PROPERTY_PROXY macros for child properties, i.e I don’t know if we 
could handle differences between gobject properties and child properties at pm level or at m4 level. What is 
your feeling about this?

Third, we need to create a new PropertyProxy. I think this is the easiest; I’ve written some code for this on 
a local branch.

Could you please comment on this?

Thank you very much.

Best regards,

On 13 Apr 2014, at 10:17, Kjell Ahlstedt <kjell ahlstedt bredband net> wrote:

2014-04-12 20:35, Murray Cumming skrev:
On Sat, 2014-04-12 at 19:16 +0200, Juan Rafael García Blanco wrote:


I’ve observed that subclasses of Gtk::Container tend to declare properties on their children. In the 
gtkmm source code I’ve read that they are used for theming so that there is no point in wrapping them. 
Does this currently hold?

Probably not.

 IMO there is no such difference between properties and child properties.

A child property is just a property of a container's child, such as it's
alignment or whether it should expand, I think. I'm sure they are
useful, if we can find a nice API for it. But it might not be necessary
to use the generic property API. Maybe all the functions do what we need
already. I don't know.

See also this 10 year old bug report:

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