GNOME Bugzilla – Bug 688973
Class naming clashes prevent extensions from installation
Last modified: 2012-12-12 18:53:59 UTC
Created attachment 229760 [details] The error from the session log. Multiple users have reported problems when installing my extension (and others, see https://bugzilla.gnome.org/show_bug.cgi?id=688355). The given error-message (from "~/.cache/gdm/session.log") is attached. It seems, that the "Type name [X] is already registered"-error is a result of another running extension with a class which has a similar name (see the issue at my extension project: https://bitbucket.org/LukasKnuth/backslide/issue/3) If this is the case, as an extension-developer, you'll have no choice but to prefix every of your classes with something unique to your extension. Proposal: Digging into the sources of the "overrides/GObject.js"-file, I see that you are already prefixing every registered class with "Gjs_" (here: http://git.gnome.org/browse/gjs/tree/modules/overrides/GObject.js#n104). An idea would be to add the extensions uuid as a prefix, too. This should then simulate a namespace (although the might be a better way...?)
The only way is to never register GTypes in extensions. Extensions are dynamic modules, and they can be loaded and unloaded - but that's not at all possible for GTypes. Even if gjs was using GTypeModule in a way compatible with extensions (which it is not), we still wouldn't be able to unload. There is no point in namespacing GTypes, if they still can't be used from extensions, so I'm closing this wontfix.
You'll have to further elaborate that. If I understand correctly, all the JavaScript bindings for libraries like Gtk or St use GTypes. How can we avoid using those and write working extensions? Or is it just the fact that I'm *extending* a GType?
Yes, that's what I meant. If you extend a GObject class (anything from St, Clutter, Gtk, etc.), you're registering a new GType, and that's not possible for extensions. Obviously, using existing classes, or "extending" them with the delegate pattern used by core shell is fine.
This "delegate pattern used by core shell" goes like this? <code> const Class = new Lang.Class({ Name: "Class", Extends: St.Button, _init:function(){ // Constructor } )}; <code> Because then, I'm using the pattern. Also, my extension works fine extending GObjects like this.
(In reply to comment #4) > Extends: St.Button, That's the issue. The delegate pattern looks like this: const Class = new Lang.Class({ Name: "Class", _init:function(){ this.actor = new St.Button(); } )};
So, it's not really extending, it's more like a proxy... I have not yet found a situation in which "really" extending GObject types was a problem (other than the name-clashes). In which case will this cause the shell to blow up or any other serious problems?
If the user wants to update the extension at runtime, or any scenario where the module might get re-evaluated. The permanence of GTypes is unfortunate, yes, and we'd love to fix it, it's just a hard problem.
Okay, I'll keep that in mind for the next update. Thanks for explaining it.
*** Bug 688355 has been marked as a duplicate of this bug. ***
Just as a quick follow-up: The gnome-shell classes from "/js/ui" are not GTypes, are they? I don't seem them extending anything that's not from the shell itself, so I assume simply extending those classes (not using the delegate pattern) is okay?
We have a few layout managers, constraints and StWidgets around, but mostly they're pure JS classes.