On 2021-10-17 07:31:09, Ian Campbell wrote: > (sorry for the delay) > > On Mon, 2021-09-27 at 09:27 -0400, Antoine Beaupré wrote: >> > Worth a try I suppose, please let me know if it works and I'll update >> > the service file in the package. >> >> Okay, will try! I do see that XDG_SESSION_ID is a thing here... > > Thanks.
And I can confirm it works, or at least does not warn. >> > Out-of-interest how does one go about activating the service file for >> > your user, I suppose you copy it to ~/.config somewhere or pass it to >> > some systemctl command -- it'd be great if I could add some >> > instructions to the docs. >> >> The post above does a lot of legwork, but basically, this is my >> .xsession: > > Thanks. It's probably a bit of a broad setup/concept for the xss-lock > docs but it's something I may try for myself at some point. Yeah, it's an emerging idea, and probably very niche, ie. restricted to non-GNOME/KDE/etc sessions... But I still think it's kind of cool. Oh, and xss-lock is awesome, thanks. Feels like a bit of too many moving parts and I'm somewhat worried about it not working sometimes, but it's much snappier than xscreensaver and "feels" a little more secure because the way the components are setup. And now that I think of it, I wonder if those processes couldn't be better sandboxed... Ideas? a. -- When I came back to the United States, I decided that if you could use propaganda for war, you could certainly use it for peace. And "propaganda" got to be a bad word because of the Germans using it, so what I did was to try and find some other words so we found the words "public relations". - Edward Bernays
