1. We really should have a hig recommendation for this.

2. I think revert is probably the best one. Users are more likely to
want to revert to their prior settings rather than the defaults, and
the behavior of cancel in other dialogs would conflict with how it
would act in an instant apply dialog. just my $.02. 

Right, I would be happy enough with Revert as well, but Seth in
particular seems to be more in favour of an Undo button, with proper
step-by-step reversion.  I can see the logic but personally I'm
unconvinced that the extra complexity is useful.

A potentially useful (but somewhat off-the-wall) compromise that I've
just thought of might be a Revert 'tool' in dialogs which, when
clicked, put you into a mode in which you could click any control in
the dialog and have only that control (or group) revert to its
original setting.  Not very accessibility-friendly though, would need
to come up with a keynavigable equivalent.

Undo with multiple rollback steps is going to need a Pong-type thing
to be implemented first. Pong-done-correctly via Glade, really.
Definitely a 2.4 or more likely 2.6 feature. Should we do something in
the 
meantime?

Well, I'd be perfectly happy to see a Revert button in every instant
apply dialog, but I may be in a minority of one there :)

Hi Guys, 

Wait, I don't understand-- are the postings above really all the
discussion on the merits of a "Defaults" button? 

I didn't see any concrete evidence presented here to support the
contention that only a "Revert" button is needed. Indeed, as more and
more new people come to Gnome from diverse backgrounds, the need to
provide them with strong safety nets in our interfaces would seem to
grow. 

The more that we can make our interfaces safe to experiment with --by
assuring users that they will always be able to get functional
settings back-- the more likely newbies are to feel safe and
comfortable with Gnome. This enables them to learn about what all
those various gnome-isms and unix-isms mean without the fear of
causing irreparable harm. 

(Try to pretend that you are a user who doesn't really like computers,
who has never used linux before, and who has about a hundred other
pressing problems to care about. If you discover that something isn't
working after playing with the control center, how would you react? If
you didnt care much for computers, it might be difficult for you to
remember exactly what you had changed where-- letting you reset your
settings to factory defaults would seem to me to be the quickest way 
to get your computer back into working order, and get you back on
track with your day.)

Anyway, the point is that I think a "Defaults" or "Use Defaults"
button could be very helpful. Havoc, I am not sure where your fear
(that having more than one extra button would be bad) comes from. Is
it that you think the dialog-action-area (uh, that is how glade calls
it-- I just mean the button-area of the dialog) would become too
crowded? Or that people would be confused by the difference between
Revert and Defaults? 

I can't address the latter question without some user testing, though
I expect that the difference between the "Revert" concept and the
"Default Settings" concept is rather clear. But as for the former...
you don't necessarily have to put this button in the same area as the
other buttons. For example, you could put it where I have it in this
screenshot (which is a very very quick hack, obviously it could be
layed-out better): 

http://primates.ximian.com/~anna/alt-button-placement.png 

(Ignore the bolding, I was playing with the idea that you could bold
the currently selected notebook tab label to show which tab is selected.) 

Anyway, this is just my long-winded 2 cents.

yours, 
Anna

With your suggested layout, having both defaults/revert looks
reasonable. Having defaults be per-page or per-control-group is maybe
an interesting idea too. 

I just don't want to see the old GNOME 1.2 control center thing with
Try, Revert, Apply, Cancel, Make Coffee, Hope for the Best, etc. ;-)

More of a question than anything...

Is a revert/default button really needed for the more simple instant
apply dialogs specifically one's where you basically are just flipping
switches (like menus and toolbars dialog). Maybe i am assuming too
much though.

I can definately see the benefit though for the keybindings and
network prefs. 

Bug 88433 is the corresponding bug filed against the HIG.

I agree that some dialogs could benefit from both a Revert and a
Defaults button, but that one or both probably needs to be optional
for simpler dialogs.  I'm not sure I like stacking them as per Anna's
mockup though... maybe it's just me, but having clusters of buttons
that span more than one row make the dialog look more complex than it
really is. *shrug*

But no, I don't have any better suggestions right now :)

I like Gregory's long-ago suggestion of small unlabled buttons,
vertically aligned in the upper right corner of the window. I think
Undo is less complex than "Revert" because it uses terminology most
users are already familiar with from document editing.... the
intention is not to provide more control but present the feature in a
way more people are likely to avail of it. I'm not sure I'd be
confident enough to touch a "Revert" button, at least not without
experimenting with it in some unimportant dialogue to see exactly what
it did.

*** Bug 104265 has been marked as a duplicate of this bug. ***

*** Bug 87331 has been marked as a duplicate of this bug. ***

I agree with Anna's 'fix' for the defaults button.. it makes much more
sense for a user i think and prevents the make-coffee button effect.

However i would strongly like to ask to call the button 'Undo' instead
of 'Revert'. Most users will know undo from their office apps,etc and
'revert' to me applies you have to 'apply' something first; Since we
are talking instant-apply dialogs, that's a weird association (Revert?
But i didnt do anything yet!) Whereas undo does not have that
connection for me (hey i'm typing or pasting something, want to 'undo'
that; Without having to 'apply' the typing or pasting first)

Last it fits better in the 'everything works the same' consitency of a
desktop to i think (undo in gimp, openoffice, etc; Why not here?) so
it benifits simplicity

What about this: when the dialog opens there would be two buttons:
[defaults] and [close], after making some modifications, the
[defaults] button would change to [undo] and if the [undo] button
would be clicked, it would undo the changes and change back to
[defaults]. Hmm, maybe it is confusing a bit, but might work well...

One problem with that idea is that it suggests the values that are
shown when you open the dialog are the default values.  More often
than not they probably won't be, if you changed those values last time
you ran the application, for example.  (Assuming that what we meant
when we were talking about Defaults earlier in the discussion was "the
default value specified in the corresponding gconf schema".)

Another potential issue is that it's better to avoid changing labels
on buttons dynamically if possible, for accessibility reasons.

Sorry for intruding, but I don't understand why is the revert button
that important, and why couldn't a defaults button substitute it fine?

The revert button reverts the preferences back to the previous state,
right?

 Assuming that most times a user goes to the preferences he changes
very few of them (except at the begining of experimenting and
configuring an app), he will remember for some time what he has
changed (if he understood what he did), and will be able to change it
back in the future, either because he remebers it, or he doesn't like
the new behaviour/option, and the preferences window will be
understandable enough to change what he wants.

Exceptions: The first times of experimenting and configuring an app,
where a user changes a lot of options at the same time, not knowing
some times what they will do;
 any other situation of a user changing a few or a lot of options and
forgetting all about them, and so also having a need to revert them
back to a proper or previous state.

I believe that for these last uses, the default button would work
fine, as the few particular uses when a user wishes to revert back
only to the previous state are very few and particular to warrant a
new button.



If anything, consider also this. There may be some confusion on the
diferences of Revert and Default for new users of computers (or even
old ones).

How about this:


[Help]             [Default Settings] [Undo Changes] [Close]

Also filed as:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=107314

*** Bug 132134 has been marked as a duplicate of this bug. ***

This is not going to happen for gnome-2.6.  There are several things
in its way

1) Do we want 'default' or 'revert this sessions changes'
2) The capplets are getting more complex, blurring the definition of
default and session.
3) It needed to have been worked on early in the development cycle. 
Changing every capplet now is not going to happen.

Changing target for GNOME 2.7

I think we can work on this for this next release as I'm hoping to see a lot of
the capplets merged.  Think about changes and perhaps we can all discuss new
solutions leading up to and at GUADEC.

While this might be a little overly complex, I think a solution with an obvious
Undo button and slightly hidden Restore Defaults button is about the solution
we're aiming at.  For this, I'm attempting to model something after the
Back/History button common in web browswers like Epiphany.

|---------------------------------------------|
|                                             |
|                                             |
|                                             |
|  [Help]                   [Undo \/] [Close] |
|                  [Restore Defaults]         |
|---------------------------------------------|

Having Undo be insensitive until changes are made in this instance of using the
capplet and Restore Defaults/Drop Down Arrow be insensitive unless the options
are different from the defaults.

(My comments added to bug 95110.)

Why is this filed against the docs component? Moving to general.

*** Bug 557117 has been marked as a duplicate of this bug. ***

Instant-apply FTW.