Shell indicator for starting, monitoring and controlling the Syncthing daemon using SystemD
Note: Binary files aren't shown on the web site. To see all files, please download the extension zipfile.
Version | Status |
---|---|
37 | Active |
36 | Active |
35 | Active |
34 | Active |
33 | Active |
32 | Rejected |
31 | Active |
30 | Rejected |
29 | Active |
28 | Active |
27 | Active |
26 | Active |
25 | Active |
24 | Active |
23 | Active |
22 | Active |
21 | Active |
20 | Active |
19 | Rejected |
17 | Active |
16 | Active |
15 | Rejected |
14 | Rejected |
13 | Active |
12 | Active |
11 | Active |
10 | Active |
9 | Active |
8 | Active |
7 | Active |
6 | Active |
5 | Active |
4 | Active |
3 | Rejected |
2 | Active |
1 | Active |
1. This extension is not 44 compatible: https://gjs.guide/extensions/upgrading/gnome-shell-45.html#shell-version 2. Please remove version (line 14 syncthing.js). 3. You cannot create instances in global scope which is the same as init (line 21 syncthing.js): https://gjs.guide/extensions/review-guidelines/review-guidelines.html#only-use-init-for-initialization 4. Use signals the new way (we have that since 43): https://gjs.guide/extensions/upgrading/gnome-shell-43.html#signals and use ESM import instead (line 19 syncthing.js): ```js import * as Util from 'resource:///org/gnome/shell/misc/signals.js'; ``` 5. Unnecessary import (line 10 syncthing.js).
1. Ok, will remove and focus on 45 only 2. Ok, will remove 3. Please clarify, I don't understand what you mean by it being part of the init of the extension itself. These objects are constants used by the implementing extension. 4. I don't see this as not OK, it does not say it's mandatory, this is how signals itself is implemented as well: https://gitlab.gnome.org/GNOME/gnome-shell/-/blob/main/js/misc/signals.js I will however change it to your suggestion, which I agree is more elegant and future proof. 5. Ok, I will remove
3. Please look at the examples in this section: https://gjs.guide/extensions/review-guidelines/review-guidelines.html#only-use-init-for-initialization Basically, when you create an instance of an object in global scope, it won't get garbage collected after disable. That's why we don't want them in global scope. 4. Yes but you shouldn't use `imports` in 45 (line 19 syncthing.js).
3. I understand what you are saying now, you weren't referring to the generic objects with constants which are permitted according to the link you gave, which in my version starts on line 21. You were referring to the logger, which is on another line now because I removed the stale imports. I'll fix it, thanks for elaborating!