Hello. xdg-screensaver has a code which seems needlessly complicated: it tries to detect the descktop environment, then if it has failed try to detect a specific screensaver. This may even be inaccurate since there might be cases where someone runs a GNOME desktop but uses xscreensaver because it has more features, for instance. Since xdg-screensaver only deals with the screensaver, I do not think it should care about the desktop environment. In fact I see no need to try to detect it: the code could be simplified by only having functions to detect and to interact with the screensaver. If you want I can try and adapt the code for that. It would be a rather heavy change but I believe it would really simplify future maintenance. Make it more straight-forward, in a way. Regards, -- Tanguy Ortolo
while I do love simplicity, do you have any concrete examples where the current code fails to do the right thing? My understanding is that it currently detects DE the "usual" way, then overrides that for 2 specific exceptions: when either xscreensaver or gnome-screensaver is detected as running.
I do not have examples where it would fail, at least not fail because of that. But while it does detect the DE, in fact it does not need to, since managing the screen saver requires knowledge of the screen saver and not of the destkop environment. My opinion is only the this DE dectection code is useless because there is no need to know anything about the DE, while it does complicate the code. For instance, real problems can be harder to track because of that artificial complexity. This is not a bug, but rather a possible enhancement…
Fair enough. I'd welcome any contribution toward simplication, sure.
While we're at it, I just committed some more robust code today detect gnome-screensaver: dbus-send --print-reply --dest=org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.GetNameOwner string:org.gnome.ScreenSaver > /dev/null 2>&1 && DE="gnome_screensaver" similar can be done for kde too: dbus-send --print-reply --dest=org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.GetNameOwner string:org.kde.screensaver > /dev/null 2>&1 && DE="kde_screensaver" While we're looking at xdg-screensaver, here's some other low-hanging fruit worth banging on: bug #30561 (basic X screensaver support) bug #41144 (xdg-screensaver error if no $DISPLAY set)
ping, any updates or progress? :)
Honestly, I forgot about it, and I do not think I shall have time to implement that idea. Simply consider this report as a suggestion, and feel free to close it if it does not help.
Rex Dieter, your code to detect gnome-screensaver would fix the bug: https://bugs.launchpad.net/ubuntu/+source/xdg-utils/+bug/1266882 I have proposed a different method for detecting (a running) screen saver in this Xfce bug report: https://bugzilla.xfce.org/show_bug.cgi?id=3770 (Please, see my recent attachment.) I wish a fix will be released soon to the above mentioned bug at launchpad.net. I wish support for light-locker (http://www.webupd8.org/2013/07/light-locker-new-session-locker-for.html) were added, too, as it is going to be used in some next Ubuntu distributions AFAIK. Also, some available daemonles locker could be used to lock as a last resort, if a screen saver can't be detected. Maybe xautolock should not be used, unless user has explicitly told so, as someone could use it for other purpose than screen locking, and it does not give any error, even if a locker is unconfigured, when user requests locking. What do you think? I think that if xdg-screensaver would be fixed and it would support more alternatives for locking, "xdg-screensaver lock" could replace scripts "xflock4" and "lxlock" in Xfce and LXDE, respectively.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xdg/xdg-utils/issues/53.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.