Created attachment 5088 Removes gnome-screensaver, adds mate-screensaver, cinnamon-screensaver, i3lock Xflock4 knows about gnome-screensaver which is dead after GNOME 3.8 but doesn't about forks: mate-screensaver and cinnamon-screensaver.
Well, I have tried to feature new ones at https://bugzilla.xfce.org/show_bug.cgi?id=3770 Proposed xflock4 there tries to find out, if a screensaver daemon is *running*. What are the daemons for those lockers you presented?
@Jarno Suni, mate-screensaver, cinnamon-screensaver; i3lock has not got any.
If i3lock gets added (which it should), how about we invoke it i3lock -c 000000 for a black screen. Thanks.
I think black screen is good idea. I would invoke it i3lock --dpms --color=000000 since --dpms enables display power control. (If you move mouse to disable display power save mode, you can re-enable it by pressing Esc.)
Created attachment 5359 Complete rewrite of xflock4 that aims to be more reliable and support more screen savers and lockers.
Why not have i3lock at the same place as other minimal lockers (xlock, slock, ...)? Isn't `xset dpms force off` the same as running i3lock with --dpms ? This patch closes several bugs, I assume?
Well, I think it is better to use i3lock's forking feature, because I suppose error handling works better in the script that way, and the Esc trick mentioned in comment 4 works only then. The other minimal lockers do not support forking. Yes, it is supposed to close several bugs.
@liquider, see this comment (and the bug report) for the the bugs: https://bugzilla.xfce.org/show_bug.cgi?id=3770#c49
On the other hand, when the display is black, i3lock does not show any user interface in the beginning. White screen may help to identify the state of the system. Not a big deal anyway, IMO.
What user interface should white i3lock show? When I run it, it's solid color (only) either way.
A dark image displaying a hint that desktop is locked and can be unlocked by typing the password of given user.
Isn't it likely that's something you have configured elsewhere? https://www.google.com/search?tbm=isch&q=i3lock
Created attachment 5370 A user friendly way to call i3lock; uses xrandr and imagemagick. The hint should be displayed on every monitor of the desktop. I don't know what you mean. If you call i3lock like the attached script, you get some visible hint after you move mouse pointer.
The script I attached in the previous comment - call it "lock.sh" here - could be included in xflock4 (but it should check whether the commands it uses are available; I think checking "convert" suffices). Support for xautolock included in the proposed xflock4 allows configuring a screen locker elsewhere: running command xautolock -nocloseerr -locker : -nowlocker PATH-TO-lock.sh as an autostarted application would do the trick.
I want to add »dm-tool lock« to the list of available lockers. »dm-tool« is provided by lightdm, which seems to become a quite popular desktop manager. I have to mention that »dm-tool« spawns a new X server at another terminal, so it's easy to bypass this locker with Ctrl + Alt + Fn if »DontVTSwitch« is not set in the xorg.conf.
@Silvio Knizek, light-locker is supposed to be more secure and to work with lightdm. Besides, the proposed xflock4 can be used to call dm-tool, id you run xautolock -nocloseerr -locker : -nowlocker "dm-tool lock" as part of application autostart. A downside of using xautolock is that xflock4 may exit before the screen is locked, as it runs the locker in background, which causes https://bugzilla.xfce.org/show_bug.cgi?id=10089
I find that light-locker does the right thing under Debian testing/unstable: by itself it will lock my laptop's screen when it suspends, which xscreensaver no longer does after the latest upower/systemd/logind shuffles. For a whole system which uses lightdm for logins, it really does look like the right approach. +1 on Jarno Suni's patch 5359. light-locker-command is sensible in that it will exit with a nonzero status if light-locker is not running, just like the commands for other screensaver daemons.
*** Bug 10913 has been marked as a duplicate of this bug. ***
Eric, the script from this bug that you just pushed to git is totally broken, in particular its guesswork of the running screensaver. pidof is not universally available (on my SUSE system it comes from Linux sysvinit) and it cannot be safely used this way. It even has a potential security impact, if multiple users are logged in and they are running different screensavers the locking can fail. Frankly, I think the xflock4 script is utter crap and broken by design. It would be both simpler, safer and a lot more sane to replace it with a xfconf setting for a command that is executed synchronously to lock the screen, possibly even with a small delay as to ensure the screen is locked before sleep/hibernate and not immediately after wakeup as it is now. It should probably be preconfigured to xscreensaver-command since xfce4-session already has a preference for xscreensaver supplying an autostart file for it.
You're right (as always). pgrep might be a better tool than pidof, availability-wise. If we go the xfconf route we can have xfpm use it if there's a value set. That way there aren't different settings everywhere. I know Simon had some ideas for locking he wrote down in the xfpm roadmap (under the 1.6 or later section) https://wiki.xfce.org/design/power-manager So if we come up with something better that would be great.
(In reply to Eric Koegel from comment #20) > You're right (as always). pgrep might be a better tool than pidof, > availability-wise. I don't think it can be reliably implemented via the process list. It is also does not seem necessary for the current cases since it is possible to query whether a screensaver is running via xscreensaver-command -v, {gnome,mate,cinnamon}-screensaver-command --query, and LightDM can be queried via DBus. > If we go the xfconf route we can have xfpm use it if there's a value set. > That way there aren't different settings everywhere. I know Simon had some > ideas for locking he wrote down in the xfpm roadmap (under the 1.6 or later > section) https://wiki.xfce.org/design/power-manager So if we come up with > something better that would be great. The proposal looks reasonable, you could ship some presets (similar to the preferred applications setting) and detect the running screensaver via the heuristics mentioned above or the availability of known lock commands in case no daemon is running. However, I'd personally favor something even more simple, i.e. just a free-form text entry for the locking command corresponding to a xfconf string. In the vast majority of use-cases a distributor or sysadmin will preinstall a preferred screensaver and the corresponding locking command can then be easily preconfigured via system-wide xfconf default setting. In case a user later consciously switches to a different screensaver, I think he probably has sufficient technical skills to adapt the locking command setting as well.
What annoys me a bit to be honest is that we currently have locking settings in the session manager settings and in xfce4-power-manager. If the settings in the session manager will be improved, I guess it would make sense to consolidate them there and simply don't show locking stuff in xfpm (e.g. "lock on suspend"), at least if xfce4-session is running / available. Guido, what you propose is very much up my alley (adding a simple xfconf option), however, given the commotion surrounding Xubuntu's switch to light-locker by default and seeing what avenues simple (and sometimes quite unexperienced and ignorant) users take to install other lockers/screensavers, I'm wondering whether some autodetection (in addition to providing a simple way for the distributor to preset a locker) wouldn't hurt. What I have in mind is something that works pretty much like the preferred apps dialog, where users can switch to other screensavers choosing from a list but also enter a custom command. (The default set by the distributor would be listed there as well obviously.) As a second step we could take a look the various bugreports surrounding xflock and xfpm-locking and consider whether to implement options/settings for some of the lockers. E.g. when a dead simple locker is used that has no screensaver integrated, it might be nice to fade to black and decrease the X11 DPMS settings (and resetting that of course upon unlock/wakeup).
Having an xfconf setting and require the user to (re)set it is no real improvement; everyone can edit and override their /usr[/local]/bin/xflock4.
Reverted the commit because it's Linux specific. http://git.xfce.org/xfce/xfce4-session/commit/?id=77cff3b344e65cccd135dc37b5324b9864946ef4
>Having an xfconf setting and require the user to (re)set it is no real improvement; everyone can edit and override their /usr[/local]/bin/xflock4. I agree and additionally an update from the distro holder could in some packagemanager overwrite the edit. I preffer the idea of "let the user decide in a dialog like what is done actually for filemanager or webbrowser".
(In reply to Pablo Lezaeta from comment #25) > I preffer the idea of "let the user decide in a dialog like what is done > actually for filemanager or webbrowser". Yes, it is easiest for the user, if he/she can setup a locker via Xfce settings manager. No need to read documentation :)
(In reply to sor.alexei from comment #0) > Created attachment 5088 > Removes gnome-screensaver, adds mate-screensaver, cinnamon-screensaver, > i3lock > > Xflock4 knows about gnome-screensaver which is dead after GNOME 3.8 but > doesn't about forks: mate-screensaver and cinnamon-screensaver. Maybe that is because gnome-screensaver is available in Ubuntu repositories, mate-screensaver and cinnamon-screensaver are not before the upcoming release 14.10. What happens if you run "mate-screensaver-command --lock" or "cinnamon-screensaver-command --lock" when a respective daemon is not running? Does it exit with nonzero code or print something in standard error or standard output? Or does it lock screen like "gnome-screensaver-command --lock"?
Created attachment 5682 Not using pidof to detect which screensaver is running, as adviced in comment 19. Does not add support for mate-screensaver and cinnamon-screensaver, yet, because I can't test it. In case xfconf implementation will not finish soon, I did try to fix xflock4.
(In reply to Eric Koegel from comment #20) > You're right (as always). pgrep might be a better tool than pidof, > availability-wise. Maybe, and how is pgrep multiuser-wise?
(In reply to Guido Berhoerster from comment #21) > I don't think it can be reliably implemented via the process list. It is > also does not seem necessary for the current cases since it is possible to > query whether a screensaver is running via xscreensaver-command -v, > {gnome,mate,cinnamon}-screensaver-command --query, and LightDM can be > queried via DBus. No need to do separate query for light-locker and xscreensaver: they won't lock, if daemon is not running.
(In reply to Simon Steinbeiss from comment #22) > What annoys me a bit to be honest is that we currently have locking settings > in the session manager settings and in xfce4-power-manager. > > If the settings in the session manager will be improved, I guess it would > make sense to consolidate them there and simply don't show locking stuff in > xfpm (e.g. "lock on suspend"), at least if xfce4-session is running / > available. IIRC some consolidation has been done already. Besides, please note that light-locker has its own setting called "Lock on suspend" that works independently of settings in the xfce4-power-manager and in xfce4-session. I think having a setting is more important for the power manager; Optional separate "Action Buttons" for suspend and lock&suspend would be nice in panel anyway for maximum flexibility (though light-locker might lock no matter which one you choose). [...] > As a second step we could take a look the various bugreports surrounding > xflock and xfpm-locking and consider whether to implement options/settings > for some of the lockers. E.g. when a dead simple locker is used that has no > screensaver integrated, it might be nice to fade to black and decrease the > X11 DPMS settings (and resetting that of course upon unlock/wakeup). "xset dpms force off" does the trick in xflock4 with those lockers. light-locker also turns off display when it locks. i3lock has --dpms option and can turn power off also, if you press Esc on lock screen.
(In reply to Jarno Suni from comment #28) > Created attachment 5682 > Not using pidof to detect which screensaver is running, as adviced in > comment 19. Does not add support for mate-screensaver and > cinnamon-screensaver, yet, because I can't test it. > > In case xfconf implementation will not finish soon, I did try to fix xflock4. The thing is that xflock4 is not fixable, it's a hack that's broken by design and needs to go away. (In reply to Jarno Suni from comment #29) > (In reply to Eric Koegel from comment #20) > > You're right (as always). pgrep might be a better tool than pidof, > > availability-wise. > > Maybe, and how is pgrep multiuser-wise? No, for non-cooperating screensavers (i.e. which provide a cli tool like xscreensaver) it is impossible to reliably implement such a check, particularly cross-platform. Instead of adding hack upon hack for obscure lockers that two people actually use, this should to be turned into a setting. So if you want to help out, you could start turning the locking command into a xfconf setting.
Created attachment 5688 Improved detection of whether gnome-screensaver is running
(In reply to Guido Berhoerster from comment #32) [...] > > (In reply to Eric Koegel from comment #20) [...] > > Maybe, and how is pgrep multiuser-wise? > > No, for non-cooperating screensavers (i.e. which provide a cli tool like > xscreensaver) it is impossible to reliably implement such a check, > particularly cross-platform. Instead of adding hack upon hack for obscure > lockers that two people actually use, this should to be turned into a > setting. So if you want to help out, you could start turning the locking > command into a xfconf setting. Well, I have not seen any bug reports concerning issues with multiple users using different screen savers simultaneously. Anyway, I may have some time for the xfconf thing. I guess it is a big/difficult task since you have not implemented it yet. I guess it would also help, if you contributed to it as well, instead of ranting how utter crap xflock4 is. On the other hand, if one uses light-locker, what for does Xfce have to know that it is the tool used for locking screen?
See also bug #11324.
A few things to note: * As noted in bug 5927 gnome-screensaver will never lock on idle on Xfce sessions, so I would advise we don't offer it as a option here since this behavior might be... surprising to anyone who doesn't know it. :( * I think the xfconf key is much more sustainable than hard coding a bunch of stuff in a script. * A sane distributor default and then allowing people to override it if they know would be good. * A gui dialog to set it in session prefs or xfce4-power-manager or shared between them seems good.
Created attachment 6125 Retrieve preferred lock-command from xfconf property This is a very simple patch which exposes the preferred locker through xfconf while still falling back to the "known lockers" we already have there. I would also vote for expanding the list, but this hidden option gives distributors an easy way of setting the default lock command without having to patch xflock4. Whether or not this option will be exposed to users is a different question and unrelated to this patch. My suggestion is to include this to make xflock a little less broken and inconvenient and then discuss whether we want to add a combobox for choosing lockers like I proposed in #22.
Unless I misread the feedback in -dev, this approach is a good first step in improving the screen locker selection. Pushed to master for additional testing/feedback: commit e940818853582290af21bf38d73ee26143d500ad Author: Simon Steinbeiss <simon.steinbeiss@elfenbeinturm.at> Date: Wed Mar 25 17:03:02 2015 +0100 Make screenlockers configurable through xfconf Signed-off-by: Eric Koegel <eric.koegel@gmail.com> https://bugzilla.xfce.org/show_bug.cgi?id=10217
As for attachment 6125 , what does xflock4 know about the command behind LockCommand? The command could be anything user has set in the variable as regular user. It could fork or not fork, it could be wrapped by e.g. "dash -c" or by "time". It does not sound that safe and easily manageable to me. Even if there is PATH setting in the script, the command could work it around by having an absolute path. Even if user sets the variable with sane content, say "light-locker-command -l", he/she has to take care that the respective daemon is running for the command to work.
Created attachment 6593 Yet another update for xflock4, uses separate script named command-dpms to run some lockers Sorry, guys, this update does not include support for xfconf variable. I tried to make this work even with older xfce4 releases, so maybe it could be backported to fix some bugs. It uses a separate script called command-dpms to restore dpms state after certain lockers quit. (I will upload it as a separate attachment.) The update is supposed to fix bug 8830, bug 9063, bug 10217, bug 10679, bug 11254, bug 11446, bug 12282, and work around bugs 9574, https://bugs.launchpad.net/ubuntu/+source/gnome-screensaver/+bug/1536237 and https://bugs.launchpad.net/ubuntu/+source/light-locker/+bug/1536238 The script is in debugging mode. In final release, "set -o xtrace" could be removed or changed to "set +o xtrace", and ':/usr/local/bin' could be removed from the PATH export.
Created attachment 6594 command-dpms Name this script as command-dpms and place in /usr/local/bin or in another directory used by xflock4. This script handles restoring DPMS state after locking finishes with certain lockers, so that xfpm's possible presentation mode is working after locking ends.
Maybe it is worth adding "\unalias -a" before setting PATH, as the manual page of 'command' suggests.
Created attachment 6595 Update to attachment 6593 . This is more backwards compatible version of xflock4. \unalias -a added. Older version of light-locker-command, e.g. 1.4.0, does not have --query option. To support it and e.g. 1.6.0, a more complicated check is done as for light-locker. (Note https://bugs.launchpad.net/ubuntu/+source/light-locker/+bug/1536238). Simpler script can be used, if you know the version of light-locker that is used with the script. As another update, added in the beginning "\unalias -a" to clean the table of aliases just in case.
Comment on attachment 6593 Yet another update for xflock4, uses separate script named command-dpms to run some lockers Requires a recent version of light-locker command, that supports --query option, to work.
Created attachment 6604 xflock4 for new light-locker that supports --query option Put the /usr/local/bin in the beginning of PATH so that administrator can override distribution's xflock4. Add \unalias -a in the beginning to disable aliases.
Created attachment 6605 xflock4 that works also with an older version of light-locker. Put the /usr/local/bin in the beginning of PATH so that administrator can override distribution's xflock4. Add \unalias -a in the beginning to disable aliases.
The reason why I changed i3lock to use --nofork and not use --dpms and call it via command-dpms is a bug in i3lock: https://bugs.launchpad.net/ubuntu/+source/i3lock/+bug/1380728
Corrective for comments 45 and 46: I added the /usr/local/bin in the beginning of PATH mainly because xflock4 should find the script command-dpms, I think preferably the version of the script possibly modified by an administrator. (At least for testing, I don't want to put it in /usr/bin. On the other hand, as there is currently no command-dpms in /usr/bin, adding the dir at the end of PATH would do as well for command-dpms.) As a side effect, xflock4 seachers for lockers first in /usr/local/bin. I don't know, if /usr/local/bin is a suitable directory when using e.g. OpenBSD, though. Anyway, setting PATH inside xflock4 does not make a difference on how xflock4 is found by the system.
Created attachment 7168 command-dpms script to be called from xflock4 Added GPL licence text. Use portable printf instead of echo.
Created attachment 7169 command-dpms script to be called from xflock4 changed content type to plain text so that you can see the file in browser.
Created attachment 7170 xflock4 for new light-locker that supports --query option Remove comment about 'which'. Aliases do not seem to be an issue in non-interactive shell. zsh. zsh can not make an array by 'set'. Who uses zsh as sh anyway? Even using bash is potentially unsafe, as even regular builtins can be shadowed by shell functions exported from environment.
Created attachment 7171 xflock4 that works also with an older version of light-locker. Removed comment about 'which' from this, too. Do not enable xtrace option.
Created attachment 7172 xflock4 for new light-locker that supports --query option Correct the shebang.
Created attachment 7213 xflock4 that works also with an older version of light-locker. Catch error code correctly. Highest preference is for running screensaver, then for locker set in xfconf property. Reset IFS.
Created attachment 7214 xflock4 that works also with an older version of light-locker. Handle field spitting better
Created attachment 7215 xflock4 for new light-locker that supports --query option Highest preference for running screensaver, then for the locker defined in xfconf property (channel xfce4-session, property /general/LockCommand), and then try some predefined lockers. Handle field spitting better, e.g. quoted arguments in the command.
Created attachment 7216 command-dpms script to be called from xflock4 Handle errors and field spitting better.
It seems the background process does not have to be a separate script file; it could be a shell function within xflock4 file, instead.
Created attachment 7217 xflock4 that works also with an older version of light-locker. command_dpms implemented as a shell function.
Created attachment 7218 xflock4 for new light-locker that supports --query option command_dpms implemented as a shell function.
Created attachment 7219 xflock4 that works also with an older version of light-locker. Work also, if the xfconf property is unset or whitespace.
Created attachment 7220 xflock4 for new light-locker that supports --query option Work also, if the xfconf property is unset or whitespace.
The xflock4 I proposed uses fraction of a second argument in 'sleep 0.1' which is not supported by all unix implementations, but 'sleep 1' could be used, instead.
Created attachment 7247 xflock4 for new light-locker that supports --query option Not using floating point arguments for sleep for POSIX compatibility. First, use a running screensaver for locking, if detected. Added a couple more xfconf variables LockSetDPMS tells, if the script should change DPMS setting with custom lock command. LockWaitComplete tells, if the script should wait until the custom command finishes before exiting the script; use 'true' with lockers that fork. If 'false', wait one second at most. If LockCommand is empty or undefined, or if it fails to run, fall back to predefined lockers.
Created attachment 7254 xflock4 for new light-locker that supports --query option Use "sleep 0.1" if system supports it. By sleep it does not use system resources that much.
-- GitLab Migration Automatic Message -- This bug has been migrated to xfce.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.xfce.org/xfce/xfce4-session/-/issues/17. Please create an account or use an existing account on one of our supported OAuth providers. If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev