Hey, a Debian user asked for a feature for xfpm (see http://bugs.debian.org/579267). Basically what would be nice would be to warn the user if she ticks the “lock screen on suspend” checkbox while there is no screensaver running (or maybe even run it in the background). One problem is that there's no easy way to detect any screensaver, and some of them don't need to run (for example xlockmore). What do you think?
I think one way to deal with this problem is to not let suspend/hibernate happen, if xflock4 fails (i.e. returns a nonzero exit code). An error message should be shown about it. (It should work similarly, when suspend/hibernate is triggered via Log Out dialog or Action Buttons.) That could be problematic, if user request suspend/hibernate when laptop lid is closed or when battery is low, though.
The error dialog in conjunction with suspend/hibernate request should be such that it gives user certain time to cancel the operation, if xflock4 fails. If user does not cancel, suspend or hibernate state (or maybe shutdown?) should be entered.
Yet, another solution is quit using xflock4 script in Xfce4, and start depending on xautolock for which to add GUI for configuration, but it might be an overkill, if you are going to use xscreensaver or new light-locker anyway.
I went with the simple approach of popping up a dialog box with the option to continue the suspend operation. My reasoning is that you'll see the dialog the first time this happens and install/fix the lock tool issue. If someone feels strongly about this not being enough, let me know (or write a patch :) The change is http://git.xfce.org/xfce/xfce4-power-manager/commit/?id=73ed5e362f7e0754b466d7d0e824ab14fec9cd17
If screen is requested to be locked after laptop lid is closed, user can not see the dialog. I suppose some audio alarm could be given that would (hopefully) make user open the lid and see the message.
On the other hand, user may notice that suspend/hibernate does not happen from a laptop LED or hard disk activity without an audio alarm. Besides this is supposed to happen only in rare exception, so I think it is not worth adding any additional alarm. As for the implementation of xfpm_lock_screen, I think it is obsolete to use gnome-screensaver in it explicitly. I guess no distribution uses gnome-screensaver by default. Well, I could not find implementation of xfpm_lock_screen in GIT, so maybe this is not an issue anymore.
Oh, found xfpm_lock_screen :) And gnome-screensaver is not alone :) The other locking methods are used in case xfce4-power-manager is installed without xfce4-session. If gnome-screensaver is kept in the list, I would suggest it is tried as the last option, since if it is installed, it will start even if its daemon is not running and even if xscreensaver's daemon is running.
I personally consider this issue fixed. There is not too much we can do about users closing their lid and not noticing the lack of screen lock. I would presume they would notice though when they reopen the lid for the first time and see the message.
Note that if the new LockCommand setting in xfconf is be used in xflock4, it is hard or impossible to know, if the xflock4 actually succeeds in locking.
I tested failing xflock4 by Xubuntu 18.04.1 live session (that has xfce4-power-manager 1.6.1-0ubuntu1). I killed light-locker and tested that xflock4 fails returning 1. Power manager is set to lock screen on suspend. Then I run 'xfce4-session-logout --suspend'. No lock, no error dialog. Same thing, if I suspend from the logout dialog.