Talk:XScreenSaver

From ArchWiki
Latest comment: 13 November 2022 by Andreymal in topic loginctl, chromium, resources

wallpaper

here's the script i generated for gentoo, vastly superior to arch wikis, can run on top of xfce4's desktop manager.

https://gist.githubusercontent.com/666threesixes666/9180979/raw/c076524fd0bb7785e8335b4bb636ae63547a5385/wallpaper

666threesixes666 (talk) 22:57, 22 March 2014 (UTC)Reply[reply]

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)Reply[reply]

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 ~~~~!Reply[reply]

Its path is /usr/lib/xscreensaver/xscreensaver-systemd -- andreymal (talk) 08:05, 16 February 2022 (UTC)Reply[reply]

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)Reply[reply]

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)Reply[reply]
  • This is true, but I don't understand why this is a problem.loginctl lock-session does 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.
-- andreymal (talk) 14:19, 22 June 2022 (UTC)Reply[reply]
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)Reply[reply]