Note: Binary files aren't shown on the web site. To see all files, please download the extension zipfile.
| Version | Status |
|---|---|
| 72 | Inactive |
| 71 | Inactive |
| 70 | Rejected |
| 69 | Rejected |
| 68 | Rejected |
| 67 | Rejected |
| 66 | Rejected |
| 65 | Rejected |
| 64 | Inactive |
| 63 | Inactive |
| 62 | Inactive |
| 61 | Inactive |
| 60 | Inactive |
| 59 | Inactive |
| 58 | Inactive |
| 57 | Inactive |
| 56 | Inactive |
| 55 | Inactive |
| 54 | Inactive |
| 53 | Inactive |
| 52 | Inactive |
| 51 | Inactive |
| 50 | Rejected |
| 49 | Rejected |
| 48 | Inactive |
| 47 | Inactive |
| 46 | Inactive |
| 45 | Inactive |
| 44 | Inactive |
| 43 | Rejected |
| 42 | Rejected |
| 41 | Inactive |
| 40 | Inactive |
| 39 | Rejected |
| 38 | Inactive |
| 37 | Inactive |
| 36 | Inactive |
| 35 | Inactive |
| 34 | Inactive |
| 33 | Inactive |
| 32 | Inactive |
| 31 | Inactive |
| 30 | Inactive |
| 29 | Inactive |
| 28 | Inactive |
| 27 | Inactive |
| 26 | Inactive |
| 25 | Inactive |
| 24 | Inactive |
| 23 | Inactive |
| 22 | Inactive |
| 21 | Inactive |
| 20 | Inactive |
| 19 | Inactive |
| 18 | Inactive |
| 17 | Inactive |
| 16 | Inactive |
| 15 | Inactive |
| 14 | Inactive |
| 13 | Inactive |
| 12 | Inactive |
| 11 | Rejected |
| 10 | Inactive |
| 9 | Inactive |
| 8 | Inactive |
| 7 | Inactive |
| 6 | Inactive |
| 5 | Inactive |
| 4 | Inactive |
| 3 | Inactive |
| 2 | Inactive |
| 1 | Inactive |
Signal should be disconnected on destroy (line 660 `extension.js`): [EGO Review Guidelines: Disconnect all signals](https://gjs.guide/extensions/review-guidelines/review-guidelines.html#disconnect-all-signals) btw, using `session-modes` isn't really helping you here because on lock, disable -> re-enable can happen (the disable can be triggered by GNOME Shell to re-base).
This signal will be automatically disconnected on destroy. See https://discourse.gnome.org/t/description-of-the-connectobject-and-disconnectobject-methods/16726/3
Ok, but what about the re-base for extensions with session modes?
What do you mean?
As mentioned before, extensions with `session-modes` **MAY** get disabled and re-enabled on lock. (Because GNOME Shell is re-basing).
Ah, now I see a new "feature" in the documentation: GNOME Shell can disable an extension even if it supports the `unlock-dialog` mode. Sadly.
Yeah, we have that in the docs: > Be aware that when the session mode changes between user and unlock-dialog, GNOME Shell may call disable() and enable() on extensions. Extensions should be prepared to handle disable() being called at any time. [Session Modes: Example Usage](https://gjs.guide/extensions/topics/session-modes.html#example-usage) Also in the [GNOME Shell 42 Port Guide](https://gjs.guide/extensions/upgrading/gnome-shell-42.html#session-modes): > Your extension will be enabled (or stays enabled) in unlock dialog. Anyway, I still think the best way to store clipboard history is to hold it in gsettings. You can store all of them in one key as json.
1. This extension already has an option to keep the clipboard history: never, only favorites or always. It seems unnecessary to me to have an additional way to temporarily save clipboard history when locking the screen (although I ended up having to do that, but I used memory for this and didn't pass moderation). 2. Let's imagine that the clipboard history contains 500 entries of 300000 characters each. Now I need to save all this to the gsettings (or file). To do this, I first need to convert all this into a string using `JSON.stringify(...)`, and then write it to the gsettings (or file). How long do you think the resulting string will be (is it possible to store a string of this length in the gsettings) and how long will all this (converting + saving) and reverse (loading + parsing) operations take? After all, these delays will lead to hanging when locking/unlocking the screen, or am I wrong? In general, it would be nice if the extension had some kind of "storage" (in memory?) where it could store some temporary data (a simple JavaScript object) between disabling/enabling the extension (when the screen is locked), and this "storage" should be automatically cleared when the user session ends or the extension is explicitly disabled by the user (or when the extension crashes). Something like this: ``` const data = getStorage(this.uuid); const entries = data.entries; if (entries) { // do something } ```
Clipman
