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

Unless the HIG is to reach beyond what can easily and well be done
now, I do not think it should make any further recommendation.

(Henceforth property or preference windows are called panels,
 as in "control panels")

It does not appear to me that the help system is fast enough or
properly tuned to show help for a particular page and thus spare
the user the time of reading irrelevant material. Even without
per page help, the system needs tuning:
  1) Help windows should be unique for a panel or app.
  2) Some form of feedback is needed until the help window is
     presented.
Once those conditions are met the Help button should be present on
each page of a panel and it should show the documentation for the
particular page.

Undo should be afforded back to the opening of a particular panel.
Only closing the panel should clear the undo history, but as a
precaution against resource hogging, there should be some set limit.
To preserve resources, actions should be compressed. While typing
a word, Undo might only remove the last typed letter; but once
a word boundary is met, Undo will remove the word.

Undo must also be per page and shown as such. Undoing should have
a perceivable effect and not jump to another page.

A button to restore "factory" defaults may be worthwhile for some
pages. A label of "Default" or "Defaults" is probably best for
English. Most alternatives are phrases or may be confusing; "Revert"
could be taken to mean reversion to the what the window displayed
when it was open, and likewise for "Reset". Where such a button
is appropriate may have to be decided case-by-case.

For undo compression, restoring factory defaults should be one step,
not however many steps would be needed to restore without the button.

The long range goal is for a page to have at most:
  [ Help ] [ Undo ] [ Defaults ]
left-aligned and no Close button.

One short range option might be what Anna showed in #94716, so
long as there is no conflict between that and the long range goal.
However, there is at least one significant problem: nothing should
change a page which is not visible and no control that applies to
only a single page should be outside of page. A lesser problem is
how to arrange things without multiple pages.

Of course, if the long range goal can be met by GNOME 2.4, then
it is mostly best to leave things as they are instead of churning
the interface.

This bug report should depend on bug reports to provide Undo stacks,
faster help, help launch feedback, and default restoration; except
insofar as those are already ready.

Since we don't have anna's recommendation from bug 94716 anymore (mockups should
be attached) Here's a simple drawn solution I'm working on.

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.

This is an attempt to keep the capplet dialogs about as clean as they are now
and to also give both kinds of undo/restore capabilities.  Since I think the
restore button is to be the least used, undo the next and close after that I've
ordered the button as such.   Help is excluded as it's a little unpredicable
when people go for that button.

Hmm, I think this could be interesting if the dropdown arrow was an actual list
of changes you'd made (or at least the controls you'd changed), plus "Restore
Defaults" at the bottom, because then you'd effectively have a "Reset" feature
as well.  The a11y infrastructure could be useful here for getting at the
accessible name of each control, which you could then show in the dropdown, and
I think you can get the mnemonic for each control this way too, so you could
have mnemonics on the dropdown for free :)

So for the Font capplet, where you'd changed the rendering option, terminal font
and app font in that order, the dropdown might look like:

[Undo v]
+-------------------+
| _Application Font |
| _Terminal Font    |
| Best _shapes      | <-- selecting this one = "reset"
|-------------------|
| _Restore Defaults |
+-------------------+

It's not clear how would handle sub-dialogs, though, e.g. the Details dialog in
this case.  You could perhaps treat all changes you made there as a single
change, and just have "Details" show up in the parent list, I guess.  (And the
sub-dialog could have its own Undo button too, for finer control while it was
open.)  And I suppose if you selected "Restore Defaults", that should appear on
the Undo list too so you could Undo it :)

(FWIW I'm still unconvinced that any dialog really needs anything more
complicated than Reset and/or Defaults, though, but maybe I'd change my mind if
I had Undo right there to play with.)

Anyway, as you say in bug 94716, let's discuss it at GUADEC :)

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

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

[Undo/Redo*]------------------------------------------[Help]
[Preferences]

[Restore Defaults]--------------------[Reset][Apply][Cancel]

Undo/Redo should be added to places where it would be useful, but probably wouldn't be necessary for every preferences window.

Setting target to 3.x, and adding 'uipattern' to whiteboard as one or more patterns could fall out of this for our (proposed) 3.x UI pattern library.

Having undo seems useful in a small number of cases, but it's not something I'd want to be generally available or recommended. Ideally, settings should be designed in such a way that it is easy to revert manually, and misconfiguration is impossible.