GNOME Bugzilla – Bug 314685
Gdmsetup UI fixes
Last modified: 2005-11-04 01:12:14 UTC
I am attaching a proposed patch for the gdmsetup dialog. This patch focuses on the General tab. The other tabs have not been changed. 2005-08-28 Dennis Cranston <dennis_cranston@yahoo.com> * gui/gdmsetup.c: (remote_toggled), (sensitive_entry_toggled_inverse), (setup_notify_toggle), (setup_greeter_toggle), (setup_gui), (main): * gui/gdmsetup.glade: HIG improvements for the gdmsetup dialog. Cleanup the layout of the General tab. Use gdmsetup.png for the dialog's icon.
Created attachment 51450 [details] [review] Proposed patch
Created attachment 51451 [details] Screenshot of changes.
Dennis: I've been working with Calum Benson doing a UI review of the gdmsetup program. I agree with Calum that it would be best to get rid of the "General", "Themed Greeter" and "GTK+ Greeter" tabs completely and replace them with a "Local" and "Remote" tab. Also I think we could merge the "XDMCP" tab with the "Remote" tab. Calum pointed out that it is a HIG violation to have more than 6 tabs and gdmsetup currently has 8. This change would bring gdmsetup back down to 6. You can see his review here, along with a number of great UI suggestions: http://www.gnome.org/~calum/usability/specs/gdm/ I suppose I could apply your patch, but it might make more sense to go in the direction Calum suggests straighaway rather than tinkering with the current "General" tab. What do you think? Would you like to help with this?
After reading Calum's review, I would recommend tossing out my patch and working on the layout recommended by Calum. I can take a shot at making these changes, but I can't guarantee anything too soon.
Thanks, that's what I thought too. No rush. Glad to have you helping.
Created attachment 51641 [details] WIP: Screen Shot of Accessibility Tab Small Update: This is a screen shot of the Accessibility tab. It is the easiest of the tabs to implement. Please feel free to make any suggestions. Thanks.
Sounds reasonable. Screenshot looks good.
Created attachment 52002 [details] WIP: Screenshot of Local Tab (Plain style) This is my design for the Local tab when using the "Plain" style.
Looks good. Note that there is another problem that has been identified in this area. Refer to bug #309697. The problem is that the same color choice in gdm.conf is used by both the Themed and the GTK greeter. Currently this causes a problem on because in the GTK+ greeter the background choice can be made insensitive - even if the Themed Greeter is actually being used. See the bug notes if I'm not making enough sense. I think the right fix is to add a new gdm.conf option so that the GTK and Themed greeter can have their own background color option. It probably makes sense to do this while you are fixing the gdmsetup GUI. Do you want me to make this fix in GDM or do you want to include it in the work you are doing?
http://www.gnome.org/~calum/usability/specs/gdm/img/local-themed.png The mockup for the themed style doesn't contain a setting for the background color. Should it have one? I would expect that when I use a theme that the background color would be defined in the theme.
You can look at gui/greeter/greeter.c at the function setup_background_color to see that the gdmgreeter does, in fact, make use of this value. It probably can be overwritten by specifying colors in the theme. I know Calum's mockup didn't take this issue into consideration since he wasn't aware of the bug report on this. However, I think we should fix this. If it does get used by the themed greeter, then the themed greeter tab should let you change it. As I said before, it probably makes more sense to have separate gdm.conf settings for the GTK and Themed background color selection.
*** Bug 315916 has been marked as a duplicate of this bug. ***
Refer to bug 315916 for some additional points about how the gdmsetup program should be improved. I think much of the work that we are doing in this bug will resolve the problems he points out. With these changes, we will no longer show both GTK+ and Themed browser configuration at the same time. I'm not sure what to do about finding better terminology for GTK+, Xserver and XDMCP. One one hand, it is good to make things simple, but on the other hand if a user isn't "advanced enough" to understand terms like Xserver and XDMCP then they probably shouldn't be trying to configure GDM.
I mentioned on the usability mailing list about the possibility of removing the "Gtk+ Greeter" tab and making it a special case of the "Themed greeter" list. Ie. have the normal list of gdm themes, with an extra theme named "Simple Dialog" which would select the Gtk+ greeter. You could then have a button to open a dialog with more advanced settings to configure the login dialog. This proposal has the advantage that it completely removes the need for a "greeter style" selection box, simplifying the GUI. I have to disagree strongly with the idea that a user shouldn't be trying to configure GDM if they don't understand technical jargon. There are a number of reasons users may want to configure their login screen and they should not be bombarded with acronyms that they don't understand if they want to do this. "Gtk+ greeter" could be replaced with something like "Simple Dialog" and XDMCP with "Remote Logon". "X Server" you cant really improve on much, except maybe calling it "screens". It seems to me that that tab should probably be buried away in an "advanced" dialog in any case.
I agree that it would be useful to have an "Advanced" button that would hide tabs that require a more advanced user. However, I worry that this might lead to a different kind of confusion. Many features that may seem "novice" have implications that may not be understood by a "novice" user. Examples include the security implications of turning on the face browser or accessibility. There is a grey area here. To be conservative from a security perspective, these features should be considered "advanced", but there are probably lots of novice users who want to turn on the face browser or accesibility. Perhaps it would be okay to leave these features in a "novice" section but have some text that explains the security issues clearly. The issue with the face browser is that it exposes usernames on the login screen. Perhaps this is obvious, but users should be aware that this has security implications. The issue with accessibility is that by turning on GTK_MODULES the sysadmin needs to be careful that the a11y configuration is loading modules that are appropriate and that the gestures defined in the gesture config files are only launching programs that are appropriate. If a sysadmin were somehow convinced to include an inappropriate GTK_MODULE or allow a gesture to be defined that would do something nasty (like launch an xterm) then this could make the system insecure. In other words, a11y should probably not be turned on blindly.
I doubt that having an "Advanced" tab will solve the problems. Instead it will tempt to clutter this "advanced" tab with all sort of stuff. Also, an "Advanced" tab is simply another way of implementing modes, simliar to the modes (novice, advanced, expert) nautilus used to have. And is it certainly bad usability to have modes. I'd rather have simple and clean solution.
To clarify: I don't envision "advanced" buttons as being a way of hiding features for users who don't understand them, rather as a way of hiding features less likely to be used unless the user really wants to set them. For example, take a look at the XDMCP tab. Most of the default settings there (maximum wait time, ping interval, etc. etc.) are options that even "advanced" users likely do not want to set. Only a small number of system administrators will want to change the settings to suit their environment. The same with my proposal for a "Simple Dialog" advanced button. It's really a way of saying, "click here for more options if you want to configure this even more". Of course, arguably the options almost nobody uses should just be removed from the GUI entirely :-)
Created attachment 52253 [details] WIP: Screenshot of Local Tab (Theme style) This is how I have designed the Local tab when using the "Theme" style.
This looks awesome, by the way. I think I agree with Simon that when we make the "Remote" tab it should have an "Advanced" checkbox which will show the stuff that is currently under the XDMCP tab and hide the XDMCP stuff if the Advanced button isn't checked. That way we can get rid of the XDMCP tab. Hopefully the Remote tab will be easier now that you have the local tab done. Aside from the XDMCP stuff the Remote tab is pretty similar to the Local tab. I think the Security, Xservers, and Users tab can pretty much stay the way they are. Although the "Users" tab could perhaps use some improvements. I don't really like the way you have to click "Apply" to make the changes take effect, but on the other hand it would make the system churn a bit much if you made the changes take effect as you go, especially if the person is adding many users. Perhaps the only real bad thing is that gdmsetup will let you exit without telling you that you didn't hit the Apply button first. Perhaps a pop-up is needed for this? The Automatic/Timed Login stuff from the General tab probably has to move somewhere. I think the Security tab makes sense since turning on Automatic login has security implications (it lets you log in without needing a password).
A few thoughts & questions: * The Security tab has only one check button remaining, "Enable dbug messages". I agree that it makes sense to move the automatic and timed login settings to the security tab. * I am not sure if having a checkbutton for toggling the display of the "XDMCP" tab is the right thing to do usability wise. I was thinking about adding a "Configure XDMCP..." button on the remote tab that opened a separate dialog. * Do the User tab settings affect all greeter styles? (i.e. plain, plain with face browser, and themed) Or, are the user settings specific to the face brower?
* Security tab I'm a little confused that you say there's only one checkbox left in the Security tab. I can understand that "allow root to login with GDM" and "Allow remote timed logins" and "Allow remote timed logins" can move to the "Local/Remote" tab, but the following seem to make sense in the Security tab: + Show Face Browser (though I guess this could move to the Users tab or to the local/remote tabs when gdmlogin is chosen. + Show Actions Menu (and the two sub-checkboxes allowing configuration from login screen and allow running Chooser from the login screen) + Deny TCP connections to Xserver (this doesn't make sense to move to the Remote tab since TCP connections to Xserver can easily happen on a local machine) and the Retry delay. + I thought Automatic/Timed login was moving to the Security tab. Though perhaps I'm misunderstanding and you've found a way to move the above options somewhere that makes more sense? * XDMCP Yes, I think that adding a "Configure XDMCP" button on the Remote tab makes sense as long as there is some text that explains that turning on XDMCP adds some security risk. The main issue with XDMCP is that it can open the door to denial-of-service attacks. Another issue is that turning on XDMCP allows people on more machines to access your machine, which could make it easier for an attacker to get into your machine. This can be mitigated to some degree by configuring GDM's TCP Wrapper support (which isn't always supported, TCP Wrappers only gets built into the code if configure can find libwrap when you build GDM). This allows sysadmins to specify which machines can access GDM via XDMCP. As long as gdmconfig is clear to the user about the issues involved with turning XDMCP on, it doesn't matter if it is on a "Security" tab. * User tab The User tab settings affect the face browser. To see the face browser in gdmlogin you have to check "Show Face Browser". To see the face browser in gdmgreeter you have to use a theme that has the face browser in the theme, such as happygnome-list. Therefore the "Show Face Browser" checkbox only has meaning for gdmlogin. I'm not sure that it is easy for gdmsetup to know if the theme supports the face browser or not. So this is a bit confusing. Also the Users tab should control the users that are in the dropdown list for Automatic/Timed login. This is broken in the last release (you have to restart gdmsetup to see the updated list in the dropdown, but fixed in CVS head). It's a bit confusing that the "Users" tab controls such different things, but it is important to have a list of "Excluded" users so gdm by default can make sure that certain users don't show up in the dropdowns or get put into the face browser (especially if "Show All Users" is checked.
Regarding the security tab, I was wrong about there only being one check button left. Here is the current break down of the Security tab. 1. Enable XDMCP: Moved to the Remote tab. The user can select "Remote login disabled" style. 2. Show Face Browser: Moved to Local tab. The user can select "Plain with face browser" style. 3. Enable debug messages to system log: Keep on Security tab. 4. Allow root to login with GDM: Moved to Local tab. The user can check "Allow system administrator to log in" option. 5. Allow root to login remotely with GDM: Moved to Remote tab. The user can check the "Allow system administrator to log in" option. 6. Allow remote timed logins: Keep on security tab. 7. Show actions menu: Moved to Local tab. 8. Allow configuration from the login screen: Moved to Local tab. 9. Allow running XDMCP chooser from the login screen: Moved to Local tab. 10. Deny TCP connections to Xserver & Retry delay: Keep on security tab or move to an Xserver dialog? So, what's left are items 3, 6, and maybe 10.
Created attachment 52377 [details] WIP: Proposed layout of the Security Tab Here is my proposal for the Security tab. Notice the "Configure Users..." & "Configure XServer..." buttons. What do you think? Thanks.
Looks good. The only thing that seems a bit confusing is the "Configure Users" button. This button is used to specify the users that appear in the face browser and also the automatic/timed login dropdown lists. There should probably be some text explaining what the "Configure Users" button does. I think the Configure Xserver button is probably clear enough that it doesn't need any extra text to explain what it does. The local/remote tabs is where a user specifies that they want to use the face browser, but there might need to be some text on those tabs to tell the user that if they want any users to show up in the face browser they need to click on this button in the Security tab and specify the users.
The original Users tab does two things. 1) It determines what users are displayed in the face browser. 2) It determines what users are listed in the username comboboxes. One idea I'd like to propose is to add two buttons for the User dialog. The first button would be a "Configure Users Displayed in Face Brower..." button that is displayed on the Local and Remote tabs when the user selects the "Plain with face browser" style. One concern I have with this approach is that the amount of vertical space used by the dialog is becoming too great. Maybe the "Allow system administrator to log in" checkbuttons could be moved back to the Security tab to help reduce the height of the dialog? A second button would be a "Configure Username Lists..." button that is displayed on the Security tab. In the Users dialog, we could display text explaining everything the dialog controls.
Created attachment 52419 [details] WIP: Screenshot of proposed "Configure Users Displayed in Face Browser" button
Hmmm. A couple of issues: + I'm not really sure that "Face Browser" stuff really belongs on the "Local" or "Remote" tabs because the face browser is used for both when it is turned on (although this isn't always true since gdmgreeter can be picked for Remote and gdmlogin be picked for Local or vice versa and one of them can have the face browser turned on and the other not). In other words, the "Face Browser" doesn't really fit nicely into the Local/Remote separation that we are moving twoards. + We seem to have lost the "Enable Face Browser" checkbox that turns on the Face Browser for gdmlogin. How do users turn this on now? Again this creates problems because the user could pick Plain for Local and Themed for remote (or vice versa). So if we go this way, then we need to put the checkbox on both the Local and Remote tab. If the user has plain set for both, then the user might think they can turn the face browser on for Local and off for Remote, but in reality there is just one gdm.conf setting that turns it on/off for both. + The Face Browser is also supported for Themed (gdmgreeter) but this is managed by picking a theme that supports the Face Browser. Since users can pick different themes for Local/Remote, in this case the Face Browser can be turned on for Local and off for Remote or vice versa. + Also it is kind of nasty that the same User configuration stuff is used for configuring the Face Browser and the drop-down list for Automatic/Timed login. If the user clicks on "Configure Users for Face Browser" and adds a bunch of users and then goes to the Security tab and clicks on the "Configure Users" button they might see those users and remove them since they don't want to see them in the Automatic/Timed login dropdowns and not realize that they are deleting users from the Face Browser as well. In other words, the "user" configuration stuff in gdmsetup is confusing. How could we fix this? Some ideas. + Perhaps we should enhance GDM so you can turn on the Face Browser separately for Local/Remote login. Then putting the checkbox for turning on/off the Face Browser in "Plain" mode on both the Remote and Local tabs would work sensibly. To do this we would need to add a new configuration option added to gdm.conf. + Perhaps gdmsetup should load the various theme xml files and look in them and see which themes have a userlist node. Then the Local/Remote tabs could have a checkbox for turning on/off the FaceBrowser in "Themed" mode. The list of themes shown in the list available could only show themes that have userlist nodes when the checkbox is clicked and show themes that do not have userlist node when the checkbox in not clicked. Doing both of the above would probably make things work nicely since we could just put the "Enable Face Browser" checkbox on both the Local and Remote tabs and for both Plain and Themed mode. + It might also make sense to change GDM so that the Face Browser and the Automatic/Timed login dropdown lists do not share the same user list. Perhaps it makes sense for Automatic/Timed login to not use a dropdown list at all. It might make sense for these to just be a text entry field where the person has to type in the username by hand. The Automatic/Timed login settings are not used by most users, and probably don't change value often so the convenience of having the dropdown list there perhaps isn't worth the confusion it creates. If we do this, then the "Configure Users" button becomes just Face Browser specific and less confusing. If it is too much work to make this work sensibly, then perhaps just keeping the "Users" tab as a separate tab makes sense for now. We can perhaps fix the usability problems with the "Users" tab as a separate step after we get all the other issues fixed.
My remarks are below next to the asterisks. ... + We seem to have lost the "Enable Face Browser" checkbox that turns on the Face Browser for gdmlogin. How do users turn this on now? Again this creates problems because the user could pick Plain for Local and Themed for remote (or vice versa). So if we go this way, then we need to put the checkbox on both the Local and Remote tab. If the user has plain set for both, then the user might think they can turn the face browser on for Local and off for Remote, but in reality there is just one gdm.conf setting that turns it on/off for both. *** My previously attached screenshot had a bug in it. The option to enable the face browser was not lost. The style combobox should have read "Plain with facebrowser", not "Plain". The "Configure Face Browser..." button would be hidden when the "Plain" style is selected. ... + The Face Browser is also supported for Themed (gdmgreeter) but this is managed by picking a theme that supports the Face Browser. Since users can pick different themes for Local/Remote, in this case the Face Browser can be turned on for Local and off for Remote or vice versa. *** Users cannot select different themes for Local/Remote. If the user selects themed for local, then on the remote tab he can only select "Same as Local" to use a themed style, but the theme will be the same. See section 2.1 of Calum's document. ... In other words, the "user" configuration stuff in gdmsetup is confusing. *** I agree. It is a mess. ... How could we fix this? Some ideas. + Perhaps we should enhance GDM so you can turn on the Face Browser separately for Local/Remote login. Then putting the checkbox for turning on/off the Face Browser in "Plain" mode on both the Remote and Local tabs would work sensibly. To do this we would need to add a new configuration option added to gdm.conf. ... * The face browser settings will only be available on one tab, not both. The user cannot select "Plain with face browser" on the Local tab and "Plain" on the Remote tab. The option on the remote tab would read "Same as Local". ... + Perhaps gdmsetup should load the various theme xml files and look in them and see which themes have a userlist node. Then the Local/Remote tabs could have a checkbox for turning on/off the FaceBrowser in "Themed" mode. The list of themes shown in the list available could only show themes that have userlist nodes when the checkbox is clicked and show themes that do not have userlist node when the checkbox in not clicked. *** I think this is outside the scope of this bug report. Maybe we can reconsider it for a future enhancement? ... + It might also make sense to change GDM so that the Face Browser and the Automatic/Timed login dropdown lists do not share the same user list. Perhaps it makes sense for Automatic/Timed login to not use a dropdown list at all. It might make sense for these to just be a text entry field where the person has to type in the username by hand. The Automatic/Timed login settings are not used by most users, and probably don't change value often so the convenience of having the dropdown list there perhaps isn't worth the confusion it creates. If we do this, then the "Configure Users" button becomes just Face Browser specific and less confusing. *** In my opinion, this is probably the better of the solutions. I keep asking myself, "Why would a user want to configure the usernames available in the drop-down list?". I don't see any real purpose for it. The drop-down list should just work (tm). Why not include all usernames in the drop-down lists? If there is a username in the list that shouldn't be used for timed/auto login then a user will not select it. I cannot think of a good use case that justifies allowing a user to configure these drop-down lists. The list should contain all usernames or just be removed. ... If it is too much work to make this work sensibly, then perhaps just keeping the "Users" tab as a separate tab makes sense for now. We can perhaps fix the usability problems with the "Users" tab as a separate step after we get all the other issues fixed. *** Perhaps. One good think about having the "Users" configuration in a separate dialog is that it would contain [Cancel] and [Apply] buttons, so the user will be less likely to not save their changes.
Dennis, glad to hear that the option for turning on the face browser was not lost. Also sorry about the confusion about having different themes for local versus remote when using gdmgreeter (Themed). Based on your comments, I guess I think the only things that I think need work are: 1. Since users can turn on the face browser in "Themed" mode by picking a theme that has a "userlist", how will users click on the "Configure Users" button? Perhaps we need to show this button in themed mode all the time perhaps with some text saying that it only takes effect if the theme selected supports the face browser? Or else gdmsetup probably needs to do some extra work to figure out which themes are which. 2. I think we should get rid of the dropdown lists for the automatic/timed login completely. It isn't appropriate to show all users since some systems use NIS and if a network has thousands (or tens of thousands of users) it can take forever to load all this information. Also the dropdown list probably is fairly useless on systems with more than a few dozen users. That said, we probably should still *not* allow users to enter usernames in the list that are in the gdm.conf "Exclude" value. This is to ensure that users that should not be allowed to login are never allowed to be used via automatic/timed login. gdmsetup currently uses the Exclude list to make sure that these userids don't appear in the list and I think we should keep this functionality. Yes I like having the users configuration in a separate dialog so the cancel and apply buttons make more sense.
To make this work correctly, the list of users excluded from the face browser should be separate from the list of users not allowed to login. Creating a UI that is simple to use will take time, so for now the Users tab will have to stay unchanged. We can revisit the issue in the future. Thanks.
I was thinking about this, and if we want to have a button on the "Security" tab that lets people edit just the Exclude list, why not pop-up the same dialog as "Configure Users" but hide the Include List frame and the frame that contains the "<" and ">" buttons? This would probably look reasonable. I think it's okay to show both the Include and Exclude list when configuring the Face Browser.
Created attachment 53967 [details] [review] Proposed Patch Here is my proposed patch! I have been using this patch on my computer without any problems for the last couple days. There were a large number of UI changes, so beware this patch is long.
This is now in CVS head. Thanks for getting this done in the 2.13 timeframe, that is really awesome. The changes you have made look beautiful. Awesome job. One missing thing, though. I notice that you defined a few new gdm.conf keys "ChooserButtonLogo and GraphicalThemeColor. You also changed the way the bakground color is set so it works with the GDM_GREETER_TYPE environment variable. You also added the GDM_BACKGROND_IMAGE_AND_COLOR option. Could you add information about these new configuration choices and interfaces in the docs/C/gdm.xml file? In general the info about how to use gdmsetup in the docs is pretty minimal. If you want to flesh out the docs a bit in this area that would be nice too. I'm also cc:ing Calum Benson so he can know what's going on. Also, you might take a look at bug #317744 which is a UI issue with gdmphotosetup. Once the docs are done I think we should close this bug. Any remaining UI fixes we need to make should probably be started in a new bug rather continuing to add to this already too-long bug report. I think the only remaining issue is that you had some ideas of how to improve the "Users" tab furhter. Thanks again.
Created attachment 54168 [details] [review] Proposed documenation patch This patch should address the documentation changes discussed in your previous comment.
Created attachment 54171 [details] [review] Proposed desktop file patch This patch updates the gdmsetup.desktop file to use the "Login Window" terminology. Since gdmsetup is a preference dialog, I changed the category from Applications->System Tools to Desktop->Administration.
Thanks Dennis, updated in CVS head. Marking this bug as fixed. If there are more issues, lets open up new bugs.