Re: Gtk::Container child properties

[Juan Rafael García Blanco <juanrgar gmail com>]

Thank you. I didn’t notice that, sorry. We’re not in a hurry I think :)

On 07 Jun 2014, at 12:03, Kjell Ahlstedt <kjell ahlstedt bredband net> wrote:

> Oops, I didn't get notified when you attached your patches to the bug report, because I was not on its CC 
> list. I've added myself now. I'll have a look at your patches, but it may take a couple of days.
>
> Kjell
>
> 2014-06-06 20:05, Juan Rafael García Blanco skrev:
> > Hi,
> >
> > I don’t want to bore you, but anyways, do you have any comments on this? 
> > https://bugzilla.gnome.org/show_bug.cgi?id=140515
> >
> >
> > Best regards,
> > Juan.
> >
> >
> > On 06 May 2014, at 22:25, Juan Rafael García Blanco 
> > <juanrgar gmail com>
> >  wrote:
> >
> >
> > > 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.