Talk:XScreenSaver
wallpaper
here's the script i generated for gentoo, vastly superior to arch wikis, can run on top of xfce4's desktop manager.
666threesixes666 (talk) 22:57, 22 March 2014 (UTC)
Start xscreensaver
Hi, Here's a way to start xscreensaver
Create in your .config/systemd/user/ a xscreensaver.service file
[Unit]
Description=XScreenSaver
[Service]
Type=oneshot
ExecStartPre=/bin/sleep 10
ExecStart=/usr/bin/xscreensaver -nosplash
[Install]
WantedBy=gdm.target
Then systemctl --user enable xscreensaver.service
Jeanmarc (talk) 07:19, 5 May 2019 (UTC)
Referenced "xscreensaver-systemd" does not exist
The current wiki says "Starting from version 5.43, XScreenSaver ships with a small utility named xscreensaver-systemd, which handles the PrepareForSleep signal from systemd using D-Bus and automatically locks the screen on suspend and hibernate. It is started automatically with xscreensaver, no further action required.", BUT this doesn't exist in the latest version in the Arch repo which is 6.02.
—This unsigned comment is by Elijah Lynn (talk) 02:25, 16 February 2022 (UTC). Please sign your posts with ~~~~!
- Its path is
/usr/lib/xscreensaver/xscreensaver-systemd-- andreymal (talk) 08:05, 16 February 2022 (UTC)
loginctl, chromium, resources
Hi, XScreenSaver author here. I have some questions about some things you have written here.
- However, it does not handle other systemd signals such as loginctl lock-session
This is true, but I don't understand why this is a problem. Under what circumstances does the screen fail to lock? The XScreenSaver manual contains instructions on how to integrate it with various desktop systems. Is this an issue if those instructions are followed? Are those instructions wrong or incomplete?
- Chromium also supports it, but uses the GNOME Session interface when available, so XScreenSaver will not be disabled in some desktop environments such as GNOME and MATE.
I have not been able to reproduce this failure mode. Can you provide more details on how and when this goes wrong?
Also: throughout this page you suggest making changes to the .Xresources file. In my opinion a far less confusing route is to edit /usr/share/X11/app-defaults/XScreenSaver instead, as that does not require messing around with xrdb or its confusing program-name or wildcard rules.
Jwz (talk) 16:59, 16 May 2022 (UTC)
- I can only comment on your last point. With Arch changes to /usr/ are strongly discouraged, as they will be overwritten on package updates.
- Regarding your Chromium point, I have added [1] for now.
- Hopefully more input coming soon.
- --Indigo (talk) 19:48, 17 May 2022 (UTC)
- This is true, but I don't understand why this is a problem. —
loginctl lock-sessiondoes nothing when using the stand-alone Openbox session, for example. The XScreenSaver manual does not mention Openbox. To make the locking work, we have to use an external tool such as xss-lock. - I have not been able to reproduce this failure mode. — I can't reproduce it today either. There were some dbus-related changes in both Chromium and XScreenSaver, some of which have probably fixed this. I think the section about Chromium can now be rewritten.
- Regarding lightson[plus]: it was added in 2011 (Special:Diff/170319), and I don't know if it's needed in 2022, but it still works (tested with MPlayer fullscreen). I decided not to touch that paragraph in the article.
- This is true, but I don't understand why this is a problem. —
- -- andreymal (talk) 14:19, 22 June 2022 (UTC)
- I finally found some time to retest everything and update the article (Special:Diff/756923), I hope it looks better now (although it may need some wording). -- andreymal (talk) 21:24, 13 November 2022 (UTC)
New XScreenSaver default config location
Apparently, the location of the XScreenSaver defaults file as referenced under resources has changed from /usr/share/X11/app-defaults/XScreenSaver to /usr/lib/X11/app-defaults/XScreenSaver.
I'm running xscreensaver v6.09, built on 07-Jun-2024, and that's where the file appears in my system after installing it via pacman -Syu.