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.ahlst...@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. >> >> > _______________________________________________ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
