Review of "Syncthing Indicator" version 32

Details Page Preview

Shell indicator for starting, monitoring and controlling the Syncthing daemon using SystemD

Extension Homepage
https://github.com/2nv2u/gnome-shell-extension-syncthing-indicator

No comments.

Diff Against

Files

Note: Binary files aren't shown on the web site. To see all files, please download the extension zipfile.

All Versions

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

Previous Reviews on this Version

JustPerfection rejected
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).
2nv2u posted a review
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
JustPerfection posted a review
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).
2nv2u posted a review
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!