This site has been retired. For up to date information, see handbook.gnome.org or gitlab.gnome.org.


[Home] [TitleIndex] [WordIndex

The current test [for inclusion in the Control Center or GNOME System Tools] is "does it require a root password?" - this is backward. The litmus test should be "does a desktop user need to do it?" - and then if it requires a root password even though a user needs to do it, we fix the root password problem. ... Note the possible change in charter: we define control-center vs. system tools by target user not by whether an action currently requires root by historical accident. -- Havoc Pennington

JohnMoser: Note systems like Ubuntu, which eliminate the "root password" in favor of sudo access. There's a libsudo, find some way to determine if sudo will allow the user to sudo the action; if not, ask for a root password. The root password should be requested iff sudo access is not possible, though a user should be able to force it to attempt to use the root password in case of wrongful detection.

Merging preferences and administration tools

GNOME configuration is currently split between "Preferences" (gnome-control-center) and "Administration" (gnome-system-tools). This split works poorly for several reasons.

Suggested plan:

  1. Let non-admins open tools that have admin-only uses. Let people explore the interface. Provide an obvious button to "unlock" the admin-only functions, where clicking it asks for an admin password.

  2. Where a tool has both admin and non-admin uses, reorganize it if necessary so that the non-admin uses are easiest to get at. (For example, rearrange "Users and Groups" so that the field for changing your own password is visible immediately when you open it.)
  3. Combine gnome-control-center and gnome-system-tools into a single menu or window.

The number of graphical config tools in GNOME is dauntingly large compared to those found in other popular operating systems (especially when distributors add their own custom tools to the mix). This is likely to make things slower to find. Suggested plan: Put related functions in tabs of the same tool. For example, we can merge:

JohnMoser: See also http://wiki.ubuntu.com/CollapsedPreferences for my spin on it. I feel my scheme is rather well developed and easy to understand, as it relates the existing tools to the new tools directly. Please e-mail me directly with comments.

What do people need to configure?

Hardware

Internationalisation

Network

All cards should dhcp automatically if there's a link. Also, we should introduce a "home or work" profile setting; but network profiles are *not* a matter of setting up two network configurations, rather they're a matter of associating other settings (such as Evolution settings) *with* the network you're on. Which network you're on should be, for the most part, automatically inferred.

UNIX User Toys

These are preferences windows/mac users don't expect or care about. We don't install these by default?

DavydMadeley: It is a fairly given fact that a lot of our migration is from UNIX... via KDE, CDE, old GNOME and the raft of other nutty window manager come desktop environments out there. I feel that these are things we probably should ship, but not make them particuarly in your face. If you've been using CDE for the last 10 years, you're probably use to searching for the options you want. Plus, the first thing I do is go and turn on sloppy focus, turn off icon names and make Alt-Tab open a terminal.

JohnPeterson: It seems sensible that when a user is first setting up a GNOME account to ask them, "What desktop interface do you prefer?" Then give them a list of choices of window managers which GNOME can emulate.

MatthewPaulThomas: Toolbar icons/text/both is highly dependent on the program -- how well you know its icons, how quickly you need to click its buttons, and how compact its windows need to be. So making it a global setting hasn't really worked, and it's made the overall interface more complicated rather than simpler (because individual programs still let you override the setting in their Customize Toolbar windows).

Making icons in menus a global setting hasn't worked either, because it's rare for any program to get around to providing an icon for all its menu items. In Microsoft Office, the presence of an icon next to a menu item means "this item has a toolbar button"; but in GNOME, the presence of an icon means nothing, and so does the lack of an icon. Perhaps this setting can be dropped too, with the HIG instructing programs to use icons only if every item in that menu/section has them (for aesthetic consistency), and only where the icon is easier to understand (e.g. the Gimp's "Layer" > "Colors") or recognize (e.g. Epiphany's "Go" and "Bookmarks") than the text is.

"What to use?"

The goal is to include all this functionality, including "what to use for X" in a similar interface. "what to use for X" can also be reasonably done from within nautilus.

Homing/Personalisation

Accessibility

Rather than making people poke through dozens of preference pages, we can create custom pref pages for users with different needs on the fly. This should be the set of all imaginable controls somebody with a particular disability (e.g. vision impaired) would need for the interface to be accessible.

CalumBenson: probably worth noting the comment from Bill in this email to gnome-accessibility-list:

We have resisted, for the most part, the temptation to put all of the features that are of interest to accessibility into a special "Accessibility" section. There are many reasons for this, including the fact that many relevant features are of general interest, the fact that some users don't self-identify as disabled, and our desire not to "ghettoize" accessibility. However, some sort of wizard or user-config helper would be useful, I agree. I think the best way to do this is via a general purpose "user profile" capability for the Gnome desktop, but this is still a project for the future.

BillHaneman: To take one example, if you're left-handed, would you look in the "Accessibility" section to change your mouse orientation?

There is also an accessibility problem with some "sudo" tools, since GUI processes running as root don't show up as accessible (because the current implementation doesn't work cross-userid, partly for security reasons). However if the GUI front end runs as the end-user, all is well.

From ControlCenter

We have lots of capplets, and some of them seem redundant or add confusion to the user (3 keyboard capplets, separated Windows and Menus&Toolbars, etc).

We also need to think about merging Administrator (from gnome-system-tools) with the normal user's preferences.


2024-10-23 10:59