GNOME Bugzilla – Bug 724009
gedit git plugin does not work anymore
Last modified: 2019-02-22 03:52:03 UTC
commit d5925b76afa3a429092cbafd82aed40bb0cf0b18 Author: Simon Feltman <sfeltman@src.gnome.org> Date: Sun Jul 28 20:45:05 2013 -0700 cache refactoring: Remove special case marshaling for instance arguments Remove duplicate code for marshaling struct and objects for instance arguments. Re-use individual cache marshalers for structs and objects with the instance argument. This required removal of passing GITypeInfo to the marshaler because it is not available for instance arguments. Instead always assume "is_pointer" for the instance argument by using the cache. https://bugzilla.gnome.org/show_bug.cgi?id=640812 This patch introduced a regression that makes the git plugin to not work. The exception I get is the next: argument self: Expected Ggit.Repository, but got gi.repository.Ggit.Repository The git plugin uses libgit2-glib which has overrides, this could be the reason. To reproduce the problem: * enable the git plugin (be sure you have gedit-plugins installed) * open a file which is inside a git repository and tracked by the repository * edit something on the file * you should get colors on the gutter in a similar way to: http://blogs.gnome.org/nacho/files/2013/01/gedit-git.png * optionally to see the exception printed above edit the plugin https://git.gnome.org/browse/gedit-plugins/tree/plugins/git/git/viewactivatable.py#n114 and print the exception you get there.
This is a regression which can most likely be fixed by replacing the introduction of "isinstance" in the mentioned commit with a "GType.is_a" check. There are also some problems with the Ggit overrides I'd to point out (and perhaps this should be added to a libgit2-glib bug): 1. The overrides don't use gi.overrides.override() for classes. https://git.gnome.org/browse/pygobject/tree/gi/overrides/Gdk.py?id=3.11.5#n71 I've verified adding this fixes the problem described here. What this does is ensures the overridden Python class is the one registered as the GType wrapper. Any function returning a GType instance of GgitRegistery will never return the overridden wrapper unless this is used. Similarly, if any function takes a GgitRegistery as an argument, it would suffer the problem described here even before the mentioned commit. 2. There are class hierarchy problems due to the usage of generically overriding classes showing up in dir(Ggit). It causes some unexpected hierarchies: gi.overrides.Ggit.Ref gi.repository.Ggit.Ref gi.overrides.Ggit.Native gi.overrides.Ggit.ObjectFactoryBase gi.overrides.Ggit.Branch gi.repository.Ggit.Branch ** gi.repository.Ggit.Ref ** gi.repository.Ggit.Native gi.repository.Ggit.ObjectFactoryBase ** Notice this does not use the overridden version of Ggit.Ref This causes the following problem: >>> issubclass(Ggit.Branch, Ggit.Ref) False I recommend explicitly overriding only classes where it is absolutely necessary (don't use dir() and don't use globals() if possible). 3. Don't use globals(), if only because it makes these problems very hard to debug and globals() should be limited to usage for debugging purposes ;) 4. I recommend using the "get_instrospection_module" API. https://git.gnome.org/browse/pygobject/tree/gi/overrides/Gdk.py?id=3.11.5#n29 5. For simple convenience related stuff, prefer helper functions to sub-classing and overrides. For instance, iterators could simply be a convenience function global to the Ggit overrides module: def git_iter(o): if hasattr(o, 'get') and hasattr(o, 'size'): for i in range(0, o.size()): yield o.get(i) else: raise ValueError("%s does not support 'get' and 'size' for iteration." % o)
For the record: https://git.gnome.org/browse/pygobject/commit/?id=9b345b1
I guess we should reopen this and reassign to libgit-glib (using gitg as a bz component for now) to follow Simon's suggestions
Additional note: The initializer overrides which call "init" should be done automatically by PyGObject. I've logged bug 724275 to track that work. What I worry about is potential breakage if we do that. For instance, is it okay to call "init" twice in cases where overrides are already attempting to take care of it? For the iterable overrides another approach could be to monkey patch "__iter__" on the classes instead of sub-classing them.
(In reply to comment #4) > For instance, is it okay to > call "init" twice in cases where overrides are already attempting to take care > of it? Turns out multiple calls to init are guarenteed to be safe: https://developer.gnome.org/gio/2.38/GInitable.html#g-initable-init
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gitg/issues/29.