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
