RE: Customize buttons that change user's customfileshouldaskforconfirmation

["Drew Adams" <drew.adams@oracle.com>]

    	    I am not sure whether
    	    the change from S => F,C into S => F is a good idea.

        Agreed. See proposal above.

    What does "proposal above" refer to?  I don't see anything
    that appears to relate to this.

My bad. I read what you wrote backward, I guess. The proposal I meant was my
proposal of 2/6/2005, which was also quoted in the mail you quote:

    Here is what I would propose:

     Set All          (F => C)
     Save All         (F => C,S)
     Get All
       Standard       (D => F)
       Saved          (S => F)
       Current        (C => F)

    1. Each button name includes "All". Likewise for menu-bar menu items.
    2. The "resetting" actions only fill the edit field; they do not set the
       current value.
    3. The "resetting" actions are combined in a button menu
       (pulldown list).

My reply to a different message also makes clear that I still think S => F
is preferable to S => C,F:

    No; I think we should avoid Reset to Saved.

    First, because it uses the confusing term "Reset" (which means
    other things in many preference editors). Second, it is simply
    Get All Saved followed by Set All, which is just two clicks
    and is much clearer. I don't see the disadvantage of the first
    group above. Why is F => C,S helpful/needed?

However, there is a typo there also. The last line should have S => F,C
instead of F => S,C.

To be clear: I prefer not to have S => F,C (Reset to Saved), but to have
instead S => F (Get All Saved) followed by F => C (Set All). Sorry for the
confusion.