GNOME Bugzilla – Bug 136204
GtkTextSearchFlags warning
Last modified: 2005-08-22 12:48:04 UTC
pytgk+-2.2.0RC1 shows next warning in my system with gtk+-2.2: ** (google.py:1393): WARNING **: `GtkTextSearchFlags' is not an flags type It seems this bug is originated by a patch trying to support gtk+-2.3, but it prints this warning with gtk+-2.2 More info: GtkTextSearchFlags is a enum type in gtk+ 2.2, but a flags type in gtk+ 2.3
This was fixed in december, I would like you to post some more information about your system. eg, what version of gtk+ you've linked to and if you're really using cvs head.
He's using your RC package IIRC. I think (per gjc) the problem is that we changed to support 2.3's flags, but broke 2.2 in the process.
Do we want a new enum-or-flags type in the .def file or do we want to allow anything declared an enum to work if the actual type is a flag? It might make sense for any enum to work if the type is changed to a flag since this apparently can occur in supposedly binary compatible releases. Either way, I can probably come up with a patch this weekend.
It sounds good if it's acheivable. I actually wanted Johan to implement something like this for a type (int_or_long) so that we could nicely deal with the problem in bug 136205 (given that we want to accept both parameters without adding an override). Do you think the code generator could handle something like that?
Created attachment 25257 [details] [review] fix using codegen ifdef and ifndef; works for me with gtk+ 2.3.4; needs testing with gtk+ 2.2
I have tested this patch with my gtk+-2.2.4 against cvs head and it fixes the warning. Good work, Gustavo.
Gustavo: did this actually change in GTK+ 2.3.4? And more importantly, what do you think of John's proposal, which could be a long-term guarantee for this sort of problem?
Reopening.. The patch checked into CVS breaks backward (or forward) compatability. Proper fix is unfortunately runtime checking.
Just to clarify a bit, the patch doesn't exactly break compatibility. It just doesn't completely prevent it. When you compile pygtk, it detects if gtk+ installed version is 2.2 or 2.4, and changes the definition of GtkTextSearchFlags to either enum or flags type, repectively. However, if the user upgrades from gtk+ 2.2 to 2.4, or 2.4 to 2.2, then the same problem reappears. But a simple recompile of pygtk solves the problem again. What Johan wants to do is do a runtime type check, and register either as flags or enum type as appropriate. I don't mind that approach, except that it feels somwhat wrong that we are working around a pygtk bug. That's why I am not willing to spend more time on this, personally. ;-)
I went ahead and modified gobjectmodule to handle anything generate constants if either a flags or an enum type is passed to either function. The rationale is that other things declared to be enums may turn into flags in future releases and vice versa (though that's less likely). With this patch, pygtk will continue to generate constants even if an end user upgrades the system's gtk library.
Created attachment 25323 [details] [review] Generate constants if either enum or flags type is found at runtime
Your patch is entirely correct. However, the following patch is smaller and more easy to understand. Do you mind if we use it instead?
Created attachment 25339 [details] [review] simplified patch
Either patch is fine with me. Sorry for the delay in responding; anyone know how to add myself to the list of people who get emailed when changes are made?
John, I've added you to the CC: list (that's what you need to do to be notified of changes to a specific bug). In case you want to be notified on *all* bug changes to gnome-python/pygtk (it's not high-volume currently), you can watch (in the email preferences tab in bugzilla) the user python-bindings-maint@bugzilla.gnome.org Reassigning to gjc.
Committed to CVS.