Review of "eclipse" version 2

Details Page Preview

eclipse clipboard interface with item encryption Added encryption of clipboard items. Encrypted items can be saved to disk in a folder of your choice. These items are persisted between sessions using openssl to encrypt the content. Eclipse uses dbus to communicate with the gpaste daemon. The following utilities are required, # for example, on fedora (add gpaste-ui for gpaste settings gui) $ sudo dnf install gpaste openssl # ubuntu $ sudo apt install gpaste openssl Now works with Gpaste 1 and Gpaste 2 on GS 3.36, 3.38 and 40 If updating the extension reports an ERROR it should work after the next reboot or if you logout and login again. If you're not running on Wayland you should be able to just restart the shell (Alt+F2,r). Please report issues on github.

Extension Homepage
https://github.com/blackjackshellac/eclipse

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
8 Active
7 Active
6 Active
5 Active
4 Active
3 Rejected
2 Rejected
1 Rejected

Previous Reviews on this Version

steeve.mccauley posted a review
FYI: Fixed a race on startup between eclipse refreshing the history menu (if it was enabled) and the gpaste session dbus. This was preventing the extension from starting after reboot if histories were enabled, which is now the default.
andyholmes rejected
- Clippie should not be a persistent singleton - Signals in `Clippie.settings_changed_signals()` should be disconnected. - Even though you're catching your errors inside Utils.execCommandAsync() you should still append a `catch()`. If something goes wrong in the `then()` or the `callback()` the Promise will persist in the main loop Fix those things and you're extension should be good to go.
steeve.mccauley posted a review
I made the change today so that the clippie object is instantiated by the indicator so will also go away when it is destroyed. Won't those signals go away when clippie is destroyed? I'll look at the issue with execCommandAsync. Thanks steeve
andyholmes posted a review
The signals should be disconnected when the last reference of the GSettings object gets dropped, but you pass that object around a bit so it wasn't clear if the settings object might outlive the object it calls back to. If you're sure that's the case, I'm okay with it too. For the Promises, you can just append `.catch(logError);` and that will handle any unexpected errors.
steeve.mccauley posted a review
Made the requested changes. Most of the files in the update just have a copyright update. Thanks