Re: gnome-stock pixmaps

[Marc Ewing <marc redhat com>]

Toshio Kuratomi <badger@prtr-13.ucsc.edu> writes:
> On Tue, 05 May, 1998 at 06:30:16PM +0200, Guillermo S. Romero / unnamed / Fam
> ilia Romero set free these words:
> > >> initial_state.
> > >> change1
> > >> Apply
> > >> change2 change3 Apply
> > >> Undo [reverts to initial+change1]
> > >> Undo [reverts to initial_state]
> > >> 
> > >> Close would be active after either an Apply or an
> > >Undo (only inactive after a
> > >> change.)
> > 
> > So you are saying that I must Apply+Undo+Close if a change something but I
> > do not like it.
> > 
> No -- two clicks: Undo+Close
> (Sequence like so: change=>Apply|Undo=>[Undo]=>Close)
> 
> > Close and help should be avaliable always. The function is immediate, so yo
> u
> > can close after change anything without appling (for example you change a
> > number by error, with you system you must apply and undo before close).
> > 
> If Close means (Apply+Close) then Close should be available always.  However,
> this means that people who don't want changes to be applied must hit a Cancel
> button which is notorious for doing something different in every app that it
> appears: Cancel can equal (undo to initial state+Close) (undo to last
> Apply+close)  and others less enticing.
> 
> Russell Nelson proposed Close, apply, undo instead of close, apply, cancel
> and proposed that close mean (Close) without apply [and therefore, should not
> be available unless the state of the dialog is known via Apply, undo, or no
> change.]

Bruce Dodson proposed this:

 <OK/Accept> <Preview/Test> <Cancel>

 * The first button applies any changes and closes the dialog.
 * The second attempts to show the user what would happen if the changes
   were applied. Sometimes that will not be possible, in which case this
   button will not be present.
 * The third button cancels any changes and closes the dialog.

I think that "Preview/Test" best describes what users want to do
when they push that button (as opposed to "Apply").  It's a very
clean and intuitive solution.

Once I dig out from under grpm I may be writing a high-level
wrapper around the GnomePropertyBox that implements this and
ties it together the gnome_config_*() handling.  The programmer
would simply construct a table of variables/gnome_config names/
default values, add a callback, and be done.

-Marc