-
Notifications
You must be signed in to change notification settings - Fork 167
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Option to auto-clear history at shutdown (or boot if it's easier) #58
Comments
Thanks for the idea! 😄 If anyone has any idea, it will be welcomed :) |
I've done investigations and finally found this https://github.com/farseerfc/systemd-shutdown-diagnose. It's a really good example. The idea is to start a service at boot and when the service is stopped (basically shutdown and reboot), a shell script is called. Two files are needed like those that I've started to fill. /usr/lib/systemd/system/shutdown-clipboard-indicator.service :
/usr/bin/clear-at-shutdown-clipboard-indicator :
I hope I don't make mistakes because I don't know how to test it on my pc ("compile" and "make" are still weird for me). |
Nice idea! 😃 But unfortunately I don't think we can do something like this:
I would guess that there is some way of listening to a "logout" signal using the GNOME shell APIs. For example, seems like we can listen to a "PrepareForSleep" signal via the Both don't give us what we want. A simple option is to remove history in the |
I don't know those APIs, sorry. The other solution is to delete history when the module is initiate at boot, it's could be very simple, no? |
@freeroot. see #46 (comment) ;-) Basically, you can have what you've asked for by storing your clipboard history in RAM! A user level systemd unit. Instead of going onto disk (and available at next boot), it's in a tmpfs. @Tudmotu , I get and agree that systemd isn't the only init system. The above is just a hack until we get around to having an in-memory cache option, which would be more secure than using tmpfs which all apps for the given user can read. |
Hi @JPvRiel :) Thanks for this and the other comments! |
I think it's very interesting too. I want to pay attention to something : when you lock the screen of gnome, all extensions are closed and when you open your session again, all extensions are reloaded...so, this solution must delete cache not only after a reboot. I don't know if it's possible to distinguish reboot and lock/open-the-same-session-again. If it is, it can be good to investigate, if not, the new option will be necessary a hard option (that I will use anyway^^). |
@freeroot @Tudmotu I've done the tempfs thing with systemd for the logged in user. See: It does work across shell extension reloads. Nevertheless, it's a work around for now. As commented before, gnome-shell extensions probably don't get to install user level systemd units. tmpfs is an option, but remember, the X server / Linux desktop security model is really poor and all apps running under the same current user can read that file even if stored in tmpfs, hence I'd like the option of using an in memory json object rather than tmpfs. |
Hi, |
Hi, If this is too difficult to implement, what about an option to clear the clipboard at a certain interval like every day? |
"In memory" storage should not be too difficult to implement - add a boolean setting, and check its value before writing to the cache file (here). |
- related to issue Tudmotu#58 - currently not working due to a dconf schema install problem
@Tudmotu gave it a go (my first try at working on a gnome extension, and not proficient with js). I think I got most of my PR ready, but I get stuck with gsettings schema issues of some sort trying to add the option. This error happens when I try open the settings (
This is the line I added (including other needed bits) that triggers the error
I'm not 100% sure how to apply defaults, should Hacking around, I even went into
And ran
So at this point, I'm getting quite fed up with how hard gnome / dconf make it to add one simple menu item. It's required 5 entries in Any hints please? https://github.com/JPvRiel/gnome-shell-extension-clipboard-indicator |
- related to issue Tudmotu#58 - currently not working due to a dconf schema install problem
Nice! Awesome job! 😃 Only issue I see is that in line 166 you use Definitely, writing gnome extensions is one of the most difficult things I ever did 😁 No documentation, clumsy development workflow, errors are hidden in journal, no testing, etc.. Thanks for helping out! |
@Tudmotu thanks for helping spot that silly typo - obviously it was invisible to me! Will get to the PR and some santiy testing this weekend. |
PR #78 submitted. Tested it a bit. An extra tweak might be to delete registry.txt when toggled, but functional for now. |
Thanks a lot. |
Hi there, just a heads up / experience with this clear at boot feature - over and above reboot/shutdown, it also applies (looses history) when:
Not ideal, but I still prefer the security at the cost of reliable/easy clipboard history. |
Another big annoying issue with using the extension memory I've found is locking and unlocking gnome seems to reload the extension and clear the history... This will need further investigation. |
All of those situations you are describing are situations where the extensions unload from memory. So for memory-only cache file, this is expected. Not much to do about it. Can think of some other impl, such as tmp-fs that was suggested before. Not sure when is it cleared exactly, but probably not between lock/unlock. |
I read somewhere that /tmp is empty at each boot. Maybe using a cache file in this folder can distinguish reboot and relock/relog. |
Yeah, I considered that, but the "attack surface" is not as ideal. If we use tmpfs, then any process running as the user can read that file, regardless of it being in memory. Using the extension memory was better because there's extra effort/rights needed to get to the data... I've opened a separate issue for this (given this one is technically closed): #91 |
I have many texts saved from several restarts and weeks whereas it's very useless for me because I work now on things completely different compared to weeks ago.
It's a keep-privacy enhancement too.
The text was updated successfully, but these errors were encountered: