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.ahlst...@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 >> <juanr...@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.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
