Wireshark-dev: Re: [Wireshark-dev] Prefs GUI handling: Apply followed by Cancel gives incorrect
Sake Blok wrote:
Bill,
My intuitive use of the "OK", "Apply" and "Cancel" buttons would be as
follows:
- Starting point would be that the preferences used in the current instance
of WS are the same as the preferences on disk
- When the preferences window is opened, a backup copy of these preferences
are made in memory
- The user can make changes and revert them to the backup copy *before*
applying them to the current WS instance
- The user can make changes to the preferences and apply them to the current
WS instance to see the effect, only the preferences in memory are affected
- When the user clicks on cancel, the backup copy of the preferences will
again be loaded into memory and applied, so that the preferences are the
same as when the preferences display was opened, also the preferences on
disk are still unchanged.
- When the user makes changes and likes the result after applying the
changes, they will be saved to disk when the OK button is clicked.
This means that the current behavior of saving the preferences to disk on
apply need to be replaced by saving the preferences to disk on "OK" only.
Your solution would mean that there is no way of returning to the
preferences that were active when the preferences window was opened and the
"Apply" button has been pressed. So there is no way of trying out the effect
of new settings with an easy bail-out.
But that's just *my* intuitive use, not sure how others would intuitively
use the "OK", "Apply" and "Cancel" buttons.
Cheers,
Sake
Sake:
Some comments:
There was some amount of discussion back around 0.99.4 on all this in
which I was not involved. (I don't seem to be able to find the thread
at the moment).
As I think I understand things there was a consensus at that time to
implement as the default the current OK/Apply/Cancel logic wherein:
1. The OK and Apply buttons both save to disk;
2. The Cancel button reverts the state to the "last saved state" (which
I take to mean the state matching that on the disk).
3. The "old" logic with a separate Save button would be available as an
option. (In this case neither OK nor Apply save to disk).
I suspect that the old (and now available as an option) logic using
OK/Apply/Save/Cancel buttons might be similar to what you describe above.
My intent with the proposed change is not to revisit the earlier
decision but to fix what seems to me to be
incomplete/not-quite-right/inconsistent implementations of that decision.
If I've mis-understood the earlier decision and the current logic is as
intended then not-a-problem. :)
--------------
Digging into this a bit more (for the cases wherein
OK/Apply/Cancel buttons are used (with optional Save button)),
I now see that the implementations are inconsistent (AFAIKT).
Use case:
OpenPrefsWindow / <PrefChangeA> / Apply / <PrefChangeB> / Cancel
using default configuration: Ok/Apply/Cancel buttons.
1. General and Protocol prefs:
State after Apply/Cancel: without PrefChangeA
The disk contains PrefChangeA.
2. View ! Coloring Rules
State after Apply/Cancel: with PrefChangeA.
The disk contains PrefChangeA.
3. Analyze ! Display Filters
State after Apply/Cancel: with PrefChangeA
The disk contains PrefChangeA.
4. Analyze ! Enabled Protocols
State after Apply/Cancel: without PrefChangeA
The disk contains PrefChangeA.
5. Edit ! Configuration Profile
State after Apply/Cancel: with PrefChangeA
The disk contains PrefChangeA.
IOW: Some cases revert to the state as of when the Window was opened and
other cases revert to the "last saved state" (ie: the state after the
Apply).
So: I guess my question is really: Is my understanding of the previous
consensus correct ? (Ie: that Cancel should revert to the "last saved
state" (after the Apply)).
If so, then I'll do a fix for cases 1 and 4 above.
If not ....
Note: I'm discussing the OK/Apply/Cancel case *not* the
OK/Apply/Save/Cancel case.
I haven't really looked at the code for that case;
Bill
