[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Customize buttons that change user's customfileshouldaskforconfirmat
From: |
Drew Adams |
Subject: |
RE: Customize buttons that change user's customfileshouldaskforconfirmation |
Date: |
Thu, 10 Feb 2005 09:46:51 -0800 |
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.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- RE: Customize buttons that change user's customfileshouldaskforconfirmation,
Drew Adams <=