Re: Control Center must-fix draft

[Brian Crescimanno <darksheer fotographix com>]

On Wed, 2001-09-05 at 22:36, Seth Nickell wrote:
> ========Interaction / Organization Issues=========
> 
> 1) The confusing "[Try] [Revert] [OK] [Cancel]" system has been replaced
> by [OK] [Cancel]. The
> problem is that the user's ability to preview changes has been lost,
> reverting us to Windows 3.1
> preferences dialogue functionality. To get a taste for what they are
> changing users must make
> all their changes and then exit the dialogue by pressing [OK].
> 
> After some discussion, and a re-evaluation of the existing dialogue
> proposal, we propose the
> control center use "[Help]         [Undo] [Done]". Help is optional, but
> of course desirable.
> Undo only undoes the last change. Done closes the dialogue. All
> preferences should take effect
> as soon as the user changes them.
> 
> Previews of many changes may be unnecessary since the Control Center
> preference panes are
> not modal, and their changes take effect immediately. That means users
> can try them in the
> area they are interested as soon as the change is made.

Agreed on all points here.  Just as a quick comment, I know someone is
going to bring up the old "Close vs. Done" debate....to be fair to both
sides, I think both of them will work well....so let's talk to the CC
developers, and see what they think of it.

> 2) Sawfish preferences need to be completely reworked. Most of the
> options should go away, or
> be deprecated into an "advanced user" system (even that is of dubious
> value for many of Sawfishs'
> options). The user should not be exposed to the notion of the "Window
> Manager". That means that
> most of the remaining sawfish preferences will need to find better homes
> than "Window Manager".
> What is "window cycling", "shade hover", "miscellaneous", "matched
> windows", etc ?!?

Also agreed.  CC does not have to import all of the sawfish
configuration options, only the ones that are truly relevant to the
user.  Beyond that, if the user desires to do some configuration to
sawfish, they can run the configuration for sawfish directly.

> 3) Default applications needs to use the same "backend" as the File
> Types & Programs capplet.
> It should be a beginner's window into the same settings as file types &
> programs sets. That also
> means that File Types & Programs needs to be extented to include URL
> handlers.

*nod*

> 4) We assume the Sawfish appearance capplet will go away in favour of
> metathemer.

I think we need to speak with the metatheme developers and find out what
the situation is here.   Is metatheme going to be ready for GNOME2?  I'm
fairly certain it will be, but let's be sure.

> 5) Capplets should have their name in the window title bar

Why, yes...yes they should. :)

> 6) The bell settings under keyboard should be in sound, or at least
> better explained (it took
> us a while to figure out what the heck that tab was for). Better yet,
> the bell tab should
> be removed altogether or moved into the cracklets section of the control
> center.

Completely agreed....I'm not even entirely sure why we have that
configuration setting....but I'm sure someone out there finds it useful.

> 7) The sound capplet as it stands today should be removed. Having a
> beginning user preference
> for "enable sound server startup" is archane. If it really needs to
> exist (yes, I have toggled
> this myself, because libesd is broken and causes applications to hang if
> it finds a broken
> server...a fix is in CVS so we just need a release of libesd) it should
> be in the cracklet section.
> (That said, I can think of useful things to have in a sound capplet, its
> just that the existing
> items aren't it :-)
> 
> 8) The HTML Viewer should not be in the main section. In fact, it should
> use GTK+ font preferences
> by default, and probably shouldn't exist at all. How can the user know
> what changing "HTML viewer"
> will change? It probably won't change their web browser, but it'll
> change applications like 
> Evolution. That's an archane technical detail, don't expose it. Its ok
> if we find a more
> general way to express this that controls other similar text (not just
> GtkHTML text) and have
> a central place to set fonts.

Definately a detail that is better left out of user hands, and
configured into a more default setting.

> =========Icon Issues========
> 
> 1) The "Main" icon currently uses a body part. Body parts (hands, arms,
> feet, heads, eyes) should
> be avoided because various cultures will find them offensive or
> insensitive. In user testing the
> toolbox icon faired well, so perhaps either a toolbox or just a tool
> itself should be focused
> on. There is really no need for the hand (plus the way the hand is
> holding the wrench looks
> very agressive).

I'm not sure I can completely agree...but I understand the logic behind
this.



Brian