Simple GNOME Shell extension manager in the top panel For support, please report any issues via the homepage link below.
Note: Binary files aren't shown on the web site. To see all files, please download the extension zipfile.
Version | Status |
---|---|
41 | Active |
40 | Active |
39 | Rejected |
38 | Active |
37 | Active |
36 | Active |
35 | Active |
34 | Active |
33 | Inactive |
32 | Inactive |
31 | Active |
30 | Active |
29 | Active |
28 | Active |
27 | Active |
26 | Inactive |
25 | Active |
24 | Inactive |
23 | Inactive |
22 | Rejected |
21 | Rejected |
20 | Rejected |
19 | Active |
18 | Rejected |
17 | Inactive |
16 | Inactive |
15 | Inactive |
14 | Inactive |
13 | Inactive |
12 | Inactive |
11 | Inactive |
10 | Inactive |
9 | Rejected |
8 | Rejected |
7 | Inactive |
6 | Rejected |
5 | Inactive |
4 | Inactive |
3 | Inactive |
2 | Rejected |
1 | Rejected |
Sorry, I forgot the DBusProxy class need `run_dispose` in (`fubar.js` line 107-109), like in gnome-shell https://gitlab.gnome.org/GNOME/gnome-shell/-/blob/817ae5069230820f8027e44400c76e5caab56521/js/ui/calendar.js#L269-L271
unexport and null out the reference should be enough. no need to call `run_dispose()` for that.
`unexport` should be a method of `Gio.DBusInterfaceSkeleton/Gio.DBusExportedObject()` like (`fubar.js` line 94),`Gio.DBusProxy` doesn't have it. https://gjs-docs.gnome.org/gio20~2.0/gio.dbusinterfaceskeleton#method-unexport
That's an old code. No need to call `run_dispose()` for that.
Just noticed `run_dispose()`. Extensions cannot use `run_dispose()` (line 21 `fubar.js`): > This function should only be called from object system implementations. [gjs-docs: run_dispose](https://gjs-docs.gnome.org/gobject20~2.0/gobject.object#method-run_dispose)
I noticed that `run_dispose()` is widely used in gnome-shell's code, If the use cases in GNOME Shell could be considered as `called from object system implementations`. Is that rule being violated here?
Well, doesn't mean that's a good thing when it is used in GNOME Shell. You are already using `disconnectObject()` in your code which is considered the alternative and a better way of disconnecting the signals related to an object.
I don't think it's good practice, either. `destroy` and `disconnectObject` are sufficient in general, `run_dispose` here handles some corner/thorny cases like: https://gitlab.gnome.org/GNOME/gnome-shell/-/blob/448df5c58e7cd7ee6c2de1e0e57c3d7a64f5a0f2/js/ui/keyboard.js?page=3#L2002-L2004 Objects that don't have a destroy method but need to be explicitly destroyed?
We allow `run_dispose()` in some special cases though. Should I look at any specific line of the code in this package?
Nope, It won't be called in the package, but might be used in other package. It's the rarely used fallback resort, putting them together is to simplify the logic. I'm ok to separate them if that's a problem.
Yeah, please separate them so we know when you are using `run_dispose()`.
btw, we've just added the `run_dispose()` to ego review guidelines: [EGO Review Guidelines: run_dispose](https://gjs.guide/extensions/review-guidelines/review-guidelines.html#extensions-should-not-force-dispose-a-gobject)