Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] Prefs GUI handling: Apply followed by Cancel gives incorrect

From: Bill Meier <wmeier@xxxxxxxxxxx>
Date: Sun, 03 May 2009 16:55:28 -0400
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