GNOME Bugzilla – Bug 319696
Fast User Switching From Panel
Last modified: 2020-11-07 12:14:22 UTC
This bug is based on the desktop-devel-list discussion around merging FUSA into the panel. See http://mail.gnome.org/archives/desktop-devel-list/2005-October/thread.html#00232 for the prior discussion.
Created attachment 53863 [details] What a "Switch To" submenu would look like
Created attachment 53897 [details] ...And what it would look like as a dialog + menu item.
Created attachment 54030 [details] [review] FUS menuitem/dialog implementation. This patch implements the functionality of FUS as a dialog, though there appears to be a problem watching the user entries (getent) which is a new occurance.
Is there a possibility the FUS dialog could act the same way as the "Log out" dialog? (screen background turns dark, and it's placed in the center of the screen etc.)
James: if we're only adding a "Switch to" menu item (like in your screenshot), then the FUS dialog could be a separate program, independant of the panel. However, if we integrate it more, then we probably need to add the code to the panel. (this means: "wow, all this new code in the panel!!!" ;-)) I'm not sure the switch to menu item is the best option, though. Jeff suggested in bug 92277 to have two dialogs: one Logout/Switch user and the other Turn off/Reboot/Suspend/etc.
Already noted on the blog, but perhaps the menu item should say "Switch User..." rather than "Switch To..."?
Vincent: It could exist as a separate application (ala gnome-screenshot) if keeping it as a dialog is considered worthwhile, yes. The code is well tested, of course, though as noted there is a regression with newly-added/removed users, which I haven't tracked it down yet (the regressed functionality is the main reason for all the extra code, BTW, doing a DM classlib is another). I personally would prefer a submenu myself, but jamesh suggested a dialog and I figured I'd like to at least open the door to thinking of other ways to switch users besides that of OS X. The problem with merging all these functions into one (or two) dialogs is that one has to come up with a menu title that will let people know what it does. The entire point of FUS is to allow others to log in without logging out, so putting it in a "Log Out" dialog is strangeness of "Start->Shut Down" proportions. Luke: Yes, "Switch User" is better, "Change User" is better still, IMO. I'm also planning on labelling "Login Screen" as "Other" (and sticking it in the TreeView with the users if we stick with the dialog).
Would it be possible to have a submenu with the last 5 logins or whatever with the face icon, their username, and their real name in a tooltip then have the last option be to open the full dialog?
Travis: A better approach may be to use a submenu if the number of users < 5, otherwise just have a plain menuitem that goes directly to the dialog. But either way you end up having to support both the menu and the dialog, and get the disadvantages of both, depending on the situation. So while it's easier politically to do both, it's definitely harder the maintenance and support fronts, and likely on the usability one as well. Is there a consensus one way or the other on the dialog v. menu, external v. internal? I can probably whip up a quick little app and jam it into CVS if people are leaning towards an external-executable dialog, and it wouldn't be much harder to do the menu. The eternal question: What do people want? :-)
Priming some movement by getting the obvious stuff out of the way: Dialog Pros: * Matches with the rest of the items in that menu. * Can be a separate executable (which encompasses smaller desktop footprint). * Can do fancy fading ala the "Log Out" dialog. * Handles "lots" of users better (> 6 or so). * Actually have your South Park-styled face big enough to make out. Dialog Cons: * Separate executable would require a "--test" flag to see if FUS is supported. * Extra clicks, load time (particularly with an executable). Menu Pros: * All users instantly available/visible. * Already very close to the current pointer location. * Can be tabular for "huge" user lists (e.g. small-office domain/LDAP w/ ~20 people). Menu Cons: * Harder to navigate. * Small icons, tied by panel icon size (using an icon size that isn't tied-in look really weird and not-tied-in :-)). * Uglier, in that there's a submenu that isn't at the top of the menu. * Larger memory footprint, even if you never touch it.
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old feature requests in Bugzilla which have not seen updates for many years. If you still use gnome-panel and if you are still requesting this feature in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/gnome-panel/-/issues/ Thank you for reporting this issue and we are sorry it could not be implemented.