GNOME Bugzilla – Bug 679981
Fix the introspection for gtk_tree_model_filter_new
Last modified: 2015-02-07 17:01:29 UTC
gtk_tree_model_filter_new, hilariously, was being parsed as Gtk.TreeModel.filter_new. I originally thought this was because it took a GtkTreeModel as its first parameter, but it turns out that any constructor method that returns an interface is not considered a constructor. There are probably plenty of other cases like this. Overall, the constructor vs. method distinction doesn't really matter too much, so there are probably only a really small number of cases where it flat out breaks, like this.
Created attachment 218872 [details] [review] regress: Fix regress_test_versioning
Created attachment 218873 [details] [review] regress: Use G_DEFINE_INTERFACE
Created attachment 218874 [details] [review] scanner: Allow constructors that return interfaces Some constructors, rather than returning instances of their classes, return interfaces instead, like gtk_tree_model_filter_new. Make sure that we support these.
Review of attachment 218872 [details] [review]: Ah, we should make that a fatal error.
Review of attachment 218873 [details] [review]: ::: tests/scanner/regress.c @@ +3435,3 @@ +typedef RegressTestInterfaceIface RegressTestInterfaceInterface; +G_DEFINE_INTERFACE (RegressTestInterface, regress_test_interface, G_TYPE_INVALID) G_TYPE_OBJECT instead of G_TYPE_INVALID please (yeah, this bug existed in the original code, but still).
Review of attachment 218874 [details] [review]: This is an old issue with a complicated history...see https://bugzilla.gnome.org/show_bug.cgi?id=561264 for example. We have to be very careful whenever we change the scanner heuristics, because at this point we could be breaking previously working code. One way to approach this is to get the diff of the Gio and GTK+ .gir files from before and after.
Attachment 218872 [details] pushed as 5ae44d8 - regress: Fix regress_test_versioning Attachment 218873 [details] pushed as 14eefe4 - regress: Use G_DEFINE_INTERFACE
Created attachment 218961 [details] [review] Difference between the two GIRs Here's the diff between the old and new Gtk-3.0 girs.
(In reply to comment #8) > Created an attachment (id=218961) [details] [review] > Difference between the two GIRs > > Here's the diff between the old and new Gtk-3.0 girs. The problem is I'm almost certain there are third party apps relying on being able to call Gtk.TreeModel.filter_new(). The function name is triggering a vague memory... What we might need to do here is maintain backcompat entries. Yes, this sucks, but dealing with these kinds of localized API breaks are extremely painful for people using scripting languages without any static checking. Asking people do do the pygtk->pygobject port is already a lot to swallow. See for example Torsten's commit: commit c47a10f867da52695a5c5b5bf7e0a22dddc0b085 Author: Torsten Schönfeld <kaffeetisch@gmx.de> Date: Sat Aug 13 12:00:00 2011 +0200 scanner: handle static methods on all types
(In reply to comment #9) > (In reply to comment #8) > > Created an attachment (id=218961) [details] [review] [details] [review] > > Difference between the two GIRs > > > > Here's the diff between the old and new Gtk-3.0 girs. > > The problem is I'm almost certain there are third party apps relying on being > able to call Gtk.TreeModel.filter_new(). The function name is triggering a > vague memory... > > What we might need to do here is maintain backcompat entries. Yes, this sucks, > but dealing with these kinds of localized API breaks are extremely painful for > people using scripting languages without any static checking. Asking people do > do the pygtk->pygobject port is already a lot to swallow. There's already an override in PyGObject. Maybe we can abuse that?
(In reply to comment #10) > There's already an override in PyGObject. Maybe we can abuse that? Yeah, just for pygobject. I'm not finding any hits in the core gjs apps (gnome-documents, etc.) for this, but who knows about third party. What we should do though is make sure we have a Regress test case for the *current* behavior first, and then look at changing it. Besides GTK+ the other question is about other *libraries*. It's probably unusual...but this is where I want to be able to toss the patch at a try server build and see what .gir changes result...
(In reply to comment #9) > The problem is I'm almost certain there are third party apps relying on being > able to call Gtk.TreeModel.filter_new(). The function name is triggering a > vague memory... That's because we've been here before: <https://bugzilla.gnome.org/show_bug.cgi?id=646742>. The patches attached there also implement the suggested backcompact scheme.
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find.
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of bug 646742 ***
[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]