Re: Gtk::Container child properties



Hi,

I managed to get GtkContainer child properties working ^^ No matter this gets accepted or not, I’m quite 
happy to have dug into gtkmm internals quite successfully :)

I’ll attach patches soon in the bug report for you to review them.

(I just wanted to share this with you; I know this is a pretty easy thing to do)

Best regards,
Juan.

On 28 Apr 2014, at 11:01, Kjell Ahlstedt <kjell ahlstedt bredband net> wrote:

It must be possible to build glibmm without access to gtk+ or gtkmm. Gtkmm header files must not be 
included in glibmm source code. In that respect glibmm must be independent of gtkmm.

In a weaker sense of the word, I think some dependence would be acceptable. E.g. gmmproc might handle a 
_WRAP_CHILD_PROPERTY macro, even if there are no child properties in glibmm.
Something similar is done already. glibmm/tools/pm/WrapParser.pm handles _WRAP_CORBA_METHOD. A comment says 
that it's used in libbonobomm. (I don't know anything about it. I don't even know if it's still used.)
M4 code specific to gtkmm should be no problem. Gtkmm already has its own m4 files, e.g. 
gtkmm/tools/m4/class_gtkobject.m4 for _CLASS_GTKOBJECT.

I don't like that gmmproc uses both Python, Perl and M4. No one knows all three well. I dislike m4. It's a 
powerful text processor, but it's very different from any other programming language that I've used. I 
wouldn't mind if you write all new gmmproc code in Perl. But that's just my personal opinion.

Kjell

2014-04-26 13:51, Juan Rafael García Blanco skrev:
Hi,

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,
Juan.






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