-- Suggestion -- Logout window ( xfce4-session-logout ) focusses "Cancel"-button by default. OR Add reaction time delay for window usage. -- Current behaviour -- When logout window appears "Logout" button is focussed by default. All buttons can be pressed / used immediately. -- Reason for Suggestion -- Logout window might be triggered automatically. This happens on battery using devices when battery is too low. If this happens while writing text where the space bar is in heavy usage, the system will log the user out against the actual will of the user. In rare cases the user might want to click somewhere right in the moment, when the xfce4-session-logout screen pops up, he/she might accidentally click one of the buttons inside the logout window.
Created attachment 8317 Focusses Cancel button instead of Logout button This is a patch for preventing the accidental log out while writing on the keyboard. It will not prevent the case of accidentally click one of the buttons with the mouse.
Finally time to do some coding & testing :) Your patch works great for me, IMO no problem to get it applied to master. Just some cosmetics: /* Use this comment style */ + there are some whitespaces on the first comment line.
Best create patches with git format-patch. Like that, the name and email you provided in git automatically will be added to the patch.
Created attachment 8322 Patch for selection "Cancel" button by default I changed the comment style. git format-patch creates a patch file about something I didn't change (chinese translation) and ignores my actual changes. Therefore I used git diff.
Created attachment 8329 patch > git format-patch creates a patch file about something I didn't change (chinese > translation) and ignores my actual changes. Therefore I used git diff. "git format patch HEAD -1" will turn the latest commit into a patch ... I guess you just forgot to first commit your changes. I added your Nick / mail to the patch and generated it with git. Is it fine for you like that ? I as well changed the comment style further, to match other multi-line comments ... sorry to be a bit pedantic ;)
Looks fine to me. Thank you very much for the assistance!
Thanks for the patch, but I don't think the changeis for the better: keyboard-wise, it is already fairly simple to dismiss the logout dialog, one just needs to press ESC. It is also somewhat easy to logout/reboot/shutdown, one just needs to press 0/1/2 times to left and press enter/space. With the first proposed change we end up with two easy ways to cancel and none to previously mentioned operations. The focus on cancel button only makes sense with your second suggestion, yet it's very intrusive IMHO. The current notification issued by xfpm is more passive and less error-prone.
Thank you for your comment. > it is already fairly simple to dismiss the logout dialog, one just needs to press ESC The point of this change is not make dismissing easier. It's to prevent accidental "ok"s. > one just needs to press ESC. Like I stated before: If you're writing something you make heavy use of "space" and "enter". You make almost no use of "esc". Therefore the probability to accidentally hit "logout" is imo fairly high for a portable office machine. > With the first proposed change we end up with two easy ways to cancel and none to previously mentioned operations. I would follow the "the default option should be the save option"-principle. > The current notification issued by xfpm is more passive and less error-prone. I don't understand this one. What do you "current notification" do you mean? regards
(In reply to DarkTrick from comment #8) > > it is already fairly simple to dismiss the logout dialog, one just needs to press ESC > The point of this change is not make dismissing easier. It's to prevent > accidental "ok"s. AFAICT currently it's not so easy to mistakenly open the logout dialog, is it? > > one just needs to press ESC. > Like I stated before: If you're writing something you make heavy use of > "space" and "enter". You make almost no use of "esc". Therefore the > probability to accidentally hit "logout" is imo fairly high for a portable > office machine. > > With the first proposed change we end up with two easy ways to cancel and none to previously mentioned operations. > I would follow the "the default option should be the save option"-principle. Again, I don't see how the logout dialog would pop up when the user is writing, playing, browsing, etc. I mean that dialog only appears when the user means it. And when using the keyboard (alt+f4 when no window is focused), with the proposed patch, the user will need to move away from the "safe" option. > > The current notification issued by xfpm is more passive and less error-prone. > I don't understand this one. What do you "current notification" do you mean? Depending on the configuration, Xfce4-power-manager may send a notification asking the user what to do when the battery level is critical.
> Xfce4-power-manager may send a notification asking the user what to do when the battery level is critical. Sending this notification is afaik the default setting. ( I can't remember changing it ) > AFAICT currently it's not so easy to mistakenly open the logout dialog, is it? > I mean that dialog only appears when the user means it. Based the the notification settings of Xfce4-power-manager, it does appear, when the user does not mean it. I understand that for the user who is always using power via an electrical outlet this is not a problem. However: - Mobile clients are in use with xubuntu (and might increase). - Mobile clients can run low on battery. - "show logout dialog" might be triggered without the user meaning it. ( Default or not shouldn't matter. It's configurable, so it should be safe) - "Accidental confirmation" might happen. Therefore I think it's necessary for a good user experience to supply a "safe" handling of the logout dialog. The current patch must not be the solution though. Others I can think of atm: - Focus cancel only, when triggered automatically (might be confusing because the same dialog has different behaviours) - Add a "are you sure" dialog for each option in die logout window. To be safe "no" would be the default selection here. - Make the dialog not accept user input within 1 second after appearing: Only, if triggered automatically. regards
Sorry for the long delay ... we did some testing of the xfce4-power-manager to reproduce the problem in detail and had some longer internal discussion what would be the best fix for it. Were I would have taken your fix in the beginning, other devs did not like the idea to change the keboard control behaviour of the logout dialog. In the end we agreed that it might be no good idea at all to popup an xfce4-session-logout dialog out of nowhere. ( E.g. If you are about to click something, this may as well end up in a undesired shutdown ) So finally we decided to remove the feature "ask on critical power" feature from xfce4-power-manager. There is already a Notification ( to be checked if it is a "critical" notification, so that it only disappears when acknowledged ) ... this should be sufficient to warn people on critical power level. I prepared a preleminary fix for xfce4-power-manager here: https://github.com/alexxcons/xfce4-power-manager/commits/master (I still need to verify if the said notification is critical, add the bug id to the commit message and test if it works fine if the old enum value is still active ) I am sorry for the trouble you had with building the patch .... now that you know xfce4-session and gtk a bit, possibly you are interested in taking a look into other bugs ;)
I'm glad this topic did not go silent. I didn't have time to check your fix, yet. So my following concerns might not be necessary. > So finally we decided to remove the feature "ask on critical power" feature from xfce4-power-manager. If the feature is just removed, there is no other option for notifications ( at least not on my system). There is indeed a warning at 20% (?), but that's not choosable in any menu. I would at least add on option for a popup-notification, that might be spawned. > I am sorry for the trouble you had with building the patch .... now that you know xfce4-session and gtk a bit It was a good first practice ;)
yes, I as well noticed no notification :/ ... I will add some notification and rename "do nothing" to "only notification".
Ideally use the imperative mood for consistency, same as with the other options "Ask", "Do Nothing" -> "Notify". Also I would vote for handling both "old" settings (it's only an integer, so I presume you'll re-use) "Ask" and "Do Nothing" simply as "Notify".
Yes, "Notify" will fit better. And yes, already with the proposed patch, the fallback for unknown values ("ask") will be "Notify" (currentl "do Nothing")
It sounds like you are planning to remove "Do nothing" completely from the list. Is that so? I would preserve that option. Maybe there are people who really want to have no notification at all(?)
ok, good argument. So there only should be a replacement "Ask" --> "Notify"
As far as my brain is still working tonight: yes, I would say so.
replacement "Ask" --> "Notify" does not work, since currently "Do Nothing" means "Notify" :) I dont want to switch "Do nothing" to really do nothing, since this probably would change the expected behavior on low power for many users. So I decided to just rename the shown
Created attachment 8420 patch to remove the "Ask" option meh ... enter on accident. Hope we migrate to gitlab soon. ... So I decided to just rename the shown combo box string from "Do Nothing" to "Notify". I am not yet fully happy with my patch. I still use the enum value XFPM_DO_NOTHING (currently the same enum is used for many combo boxes in xfpm-setting) Gues I should add a new enum instead.
Created attachment 8422 patch to remove the "Ask" option > I am not yet fully happy with my patch. I still use the enum value XFPM_DO_NOTHING (currently the > same enum is used for many combo boxes in xfpm-setting) > Gues I should add a new enum instead. Done. Now I am happy with my patch :)
Now I just need to wait till my system drops below 20 % to see if the fallback of ask works like expected. :F
Created attachment 8433 patch to remove the "Ask" option - missed to replace one instance of the old enum. - now replacement of "Ask" in xfconf is directly done after xfconf_channel_get_uint. .. sorry, hope this time the patch reached a final state.
Created attachment 8438 notification with buttons Just tested under real conditions... crazy stuff, I now get a Notification, even containing an ask dialog (see screenshot) :P The notification does not react to keystroke, only to mouseclick ! It needs to be clicked to disappear. I tried "shutdown", which worked for me. So seems to be perfect. If you have time, please give the patch a spin and let me know if it works for you ! (After a test by somebody else I would consider the patch to be ready to push)
While your patch (https://bugzilla.xfce.org/attachment.cgi?id=8433) works in the sense that "Notify" now shows a notification, it also removes the "Do nothing" you seemed to agree to keep after https://bugzilla.xfce.org/show_bug.cgi?id=15158#c16 Wasn't this the plan? "Ask" -> "Notify" (send notification instead of show logout dialog) "Do Nothing -> "Do Nothing" (actually do nothing, not even sending a notification)
I guess this is because: > replacement "Ask" --> "Notify" does not work, since currently "Do Nothing" means "Notify" :) > I dont want to switch "Do nothing" to really do nothing, since this probably would change the expected behavior on > low power for many users. So I decided to just rename the shown Although on my system nothing happens. Maybe I'm doing something wrong in testing...
> replacement "Ask" --> "Notify" does not work, since currently "Do Nothing" means "Notify" :) > Created attachment 8438 > notification with buttons To me it seems like the "bubble notification" feature is gone now. Am I right? Shouldn't your "notification with buttons" be on "ask"? Option: "Do nothing" -> rename to "Notify" (creates the bubble notification) Option: "Ask" => Did we agree to remove it completely? Or do we replace it with your "Notification with buttons"?
Also, it would be nice to be able to test the behaviour without the need to wait for 20% battery. Therefore I tried to implement a direct call to xfpm_power_system_on_critical_power() from the outside. However, it seems I'm not able to instantiate Xmpf_power or Xmpf_Battery. Would be nice to add such a feature at least for testing for the moment.
Created attachment 8466 yet another crit GUI I just found out that there are two options for the Notification. If notify_get_server_caps() contains the item "actions" as TRUE, than the Notification shown above will be launched. If that is not the case, some self-build gtk GUI will be launched (yes, yet another GUI, different from xfce-session-logout :P ... see screenshot ) Since what we want is always Notification, no self-build GUI, I would dump all the code related to this extra GUI. From https://developer.gnome.org/notification-spec/ > Table 5. Server Capabilities > "actions" The server will provide the specified actions to the user. Even if this cap is missing, actions may still be specified by the client, however the server is free to ignore them. So even if "actions" is not supported, a notification without buttons would be shown.
Naively I would say "yes", but I have the feeling it's necessary to examine under what circumstances notify_get_server_caps() contains actions as TRUE. Why would someone take the effort of building it in the first place..
My assumption would be, that libnotify added support for "actions" in a specific version. I use a debian, which is rather conservative .. and even debian has "actions=TRUE" per default. On top, the enum entry in xfpm-settings is called "Notify" .. so the actions are only a nice add, not mandatory. So this extra GUI actually is dead code which almost nobody ever will see. Nevertheless it would need to be maintained (e.g. if we move to gtk4 some day) .. that's why I would say: lets dump it. ( Related: xfpm anyhow should switch to xfce4-notifyd at some later point, which supports actions )
> If notify_get_server_caps() contains the item "actions" as TRUE, than the Notification shown above will be launched. > debian, which is rather conservative .. and even debian has "actions=TRUE" per default. I think this is a typo or a misunderstanding on my side, but wouldn't this mean, that the dialog is always shown on debian? (Don't want to be picky, but clear things up :) )
Currently. if you select "do Nothing" , this one will be shown per default: https://bugzilla.xfce.org/attachment.cgi?id=8438 Only if you set "actions" in notify_server_caps to FALSE, this one will be shown instead: https://bugzilla.xfce.org/attachment.cgi?id=8466 ( I did not actually test the second case, just saw the logic in the code )
( I did not actually test the second case, just saw the logic in the code and faked a "FALSE" to get the GUI )
-- 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-power-manager/-/issues/48. 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