Multiple extensions from gnome-shell-extensions repo call Gio.Settings.run_dispose() to avoid disconnecting from changed signal(s) manually - at least it’s auto-move-windows, places-menu, user-theme, window-list.
However, the same call is one of the reasons my extension was rejected.
I thought gnome-shell-extensions should be an example of how to implement extensions correctly.
So, is Gio.Settings.run_dispose() call acceptable or not?
Unless there is a good reason, then no.
If you can justify why it is necessary to use GObject.Object.run_dispose() for a particular case, then it can reviewed as such, but otherwise it is not permitted to use it simply as an easy way to disconnect signals.
So it’s OK to call Gio.Settings.run_dispose()for that same reason if the extension is in GNOME / gnome-shell-extensions · GitLab ?
But those extensions are also published on extensions.gnome.org
For example, User Themes extension - User Themes - GNOME Shell Extensions - v53 from extensions.gnome.org calls .run_dispose(). Just to avoid disconnecting from changed signal.
Ironically, the commit that adds .run_dispose() has " user-theme: Extensions review guidelines compatibility" as its summary: user-theme: Extensions review guidelines compatibility (762ec756) · Commits · GNOME / gnome-shell-extensions · GitLab
I don’t understand anything now.
Can I trust GNOME / gnome-shell-extensions · GitLab as a “good example” of extension implementations?
What is that reason, though? What is your reason for using it?
It’s simple: no, it is not okay to call GObject.Object.run_dispose() in extensions.
If you can provide a rationale for why you need to use it, then that can be evaluated during review.
In user-theme:
Quoting @fmuellner
I’d also consider simplifying the
changedsignal handling by callingrun_dispose()before nulling the variable.
Disconnecting all changed signal handlers automatically in disable(), without the need to track them. Otherwise, the handlers can be called when the extension is disabled, and need to be disconnected manually.
As that appears to be a common misconception, I’ve opened extensions: Stop using run_dispose() (!275) · Merge requests · GNOME / gnome-shell-extensions · GitLab.
That’s not what GObject.Object.run_dispose() is for, and there are other methods for disconnecting signals, so I would not consider that a rationale.
I understand many developers consider this to be an undue burden, but I think the situation is overblown a little bit. It’s not so much work to disconnect signals, and ensure you’re thinking about what/when you’re connecting to them.
Unless we have a "recommended reference extensions" for extension developers to look up to, we can make "gnome-shell-extensions" as the recommended reference extensions.
Sorry, but no.
The extensions from the gnome-shell-extensions repository can be roughly categorized as:
The last category makes up half of the extensions. I have never used any of them, or care particular about the functionality they provide. Despite that, I have kept them working for over a decade, but that’s the maximum work I’m willing to invest in them.
Turning the repository into a set of “model extensions” would be additional work, and that’s not something I’m willing to do for that last set of extensions.
That is, if there is an expectation now that the repository serves a second purpose as “reference extensions”, then a precondition would be that all extensions I don’t care about personally or as part of my job are dropped first.
Until then, the extension templates included with gnome-shell and the examples on gjs.guide are better references.
For what it’s worth, most of the gjs.guide Topics now exist as fully functional examples, that can be found in their respective src/ directory. I had some vague thoughts of taking that a bit further, but there are many things to do 
I think that’s not needed now.
We now have a clear picture of where things stand. Thanks for clarifying.
Sounds good. Maybe, we can add this info in places where extension developers look for information ( if it’s not already there )
Cheers!
This topic was automatically closed 45 days after the last reply. New replies are no longer allowed.