Preferences, System Tools
- From: Havoc Pennington <hp redhat com>
- To: desktop-devel-list gnome org
- Subject: Preferences, System Tools
- Date: Fri, 04 Jun 2004 15:01:30 -0400
Hi,
The appended is sitting on the Red Hat intranet, waiting for us to get a
Fedora wiki running. This is Seth's work primarily.
The idea is to outline top-down what preferences a user would see. So
the relevance is to the system tools thread (and also general
cleaning-up of the Preferences menu).
I don't think this outline is supposed to imply a menu hierarchy or even
that each item is a separate dialog. It's just supposed to exhaustively
list what prefs we should have, and then a secondary question is where
to put them (e.g. they can be associated with applets, activated from a
dialog such as print dialog, part of nautilus, or whatever, not just
control panels).
Anything NOT on this list would be a sysadmin tool, not an end user
tool. I would argue that each tool we provide should be clearly
designated as one or the other. (And probably that maintenance/module
boundaries need to be along these lines.)
Jody points out that the current litmus test 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. D-BUS is
one way to do that (by having a root process ask the user session for a
setting).
So in the world outlined below, control-center covers everything listed
here, and if we integrated system tools the system tools package would
be an admin-focused feature.
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
Desktop Preferences
Preferences in this list should all be per-user and not require root
access to configure (at least optionally; the admin may be able to
disallow setting up specific things).
Hardware
* Screen layout (multiple monitors), resolution, and depth
* Mouse speed
* Speaker configuration: 2, 4, 5.1
* Sound volume
(may additionally have a panel presence)
* Which printer and printer options such as paper
(may additionally have presence in print dialogs)
* Power management
Internationalization
* Keyboard layout
(may additionally have a panel presence)
* Language
Network
* Select a wireless network (essid)
* Configure and sign on to VPN
* Set network proxy
Notes: 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 your on should be,
for the most part, automatically inferred.
UNIX user toys
* Toolbar icons/text/both
* Window manager prefs
* Keyboard shortcuts
Notes: preferences windows/mac users don't expect or care about. We
don't install these by default. In the RHEL/Fedora installer we include
a new package group that includes Unix User toys, emacs, xemacs, vim,
and that sort of thing, but don't install them by default anymore.
"What to use?"
* Web browser
* CD player
* email
* Text editor
* DVD player
* CD burner
Notes: The goal is to include all this functionality, including "what to
use for " in a similar interface. "what to use for " can also be
reasonably done from within nautilus.
Homing/Personalization
* Background
* Font
* Personal info (name, etc.)
* Theme
(controls cursor, gtk theme, wm theme, icon theme and provides
the option of suggesting a font and background)
Accessibility
* Key repeat rate
* Cursor blink rate
* Typing break
* Mouse speed
* Double click speed
* Drag threshold
* Pointer locator key
* Cursor size
* Left-handed mouse
* ...etc...
Notes: 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.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]