[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Customize buttons that change user's custom fileshouldaskforconfirma

From: Kim F. Storm
Subject: Re: Customize buttons that change user's custom fileshouldaskforconfirmation
Date: Thu, 03 Feb 2005 10:36:20 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/21.3.50 (gnu/linux)

Miles Bader <address@hidden> writes:

> Your table helps, but I think it's important to use the proposed
> operations, not what the current code does.  Here's my version:
>    Set:            Field => Current
>    Save:           Field => Current, Saved
>    Get Current:    Current => Field
>    Get Saved:      Saved => Field
>    Get Default:    Standard => Field
> I think these names (and behaviors) make a _lot_ of sense; the
> consistency is very appealing, and should help people learn the
> meanings easily.

The major problem IMHO with Customize is not the names for
the operations as such, but the way it differs from other
applications that the user may be accustomed to.

Customize operates with four values for each variable:

F * the field value
C * the current value
S * the saved value
D * the default value

It provides commands for the following operations:

F => C
F => C,S
C => S
C => F
S => C,F
D => C,F  or  D => F

In contrast, most other applications only have these states:

F * the field value
A * the active (current/saved) value
D * the default value

and consequently has fewer operations:

F => A           (Save, OK)
A => F           (Cancel)
D => A,F         (Clear All)  -> with confirmation

Consequently, I think the ability to set an option without saving it
is unfamiliar to most users -- when you set something and apply the
change, they will expect it to be like that from now on.

IMO, we should consider the difference between F and C states as an
expert option.

The big problem is that if the user sets option X on a page and does
<Set> "F => C", and then (sometime later) sets option Y on the same
page, and then does <Save> "F => C,S", the effect is that the change
to X is also saved.  This may be highly confusing to a user.

Also the user should be offered to save unsaved customizations when he
exits emacs.

Another idea is to combine "C => F" and "S => C,F" states into a
single <Cancel> option.  We can do this by letting <Cancel> check
if C != S and ask the user:

        Restore to last saved value (y/n)

in that case -- otherwise it just restores to C (== S).

To summarise:

I suggest the following button names:

  <Set>  <Save>  <Cancel>   <Clear All>

The <Set> button does "F => C" when enabled/confirmed.

This is an expert command, so it shall be disabled by default
(e.g. like narrow-to-region), causing Emacs to ask the novice user if
he really wants to do this.

The <Save> button does "F => C,S" and thus "C => S" when F == C.

The <Cancel> button does either "C => F" or "S => C,F".

Unless the user has previously used <Set> for any of the
variables on the page (so C != S), the effect is the same.
If C != S, it asks the user:
        Restore to last saved value (y/n)
and acts accordingly.

The <Clear All> button first asks the user for confirmation. 

If ok it does "D => F"  (does not update C or S).

It then prints a message
   Remember to use <Set> or <Save> to activate/save the values.

Kim F. Storm <address@hidden> http://www.cua.dk

reply via email to

[Prev in Thread] Current Thread [Next in Thread]