GNOME Bugzilla – Bug 488270
properties dialog should have a button to undo all changes made while interacting with the dialog
Last modified: 2019-03-20 11:35:57 UTC
The properties dialog has three buttons: "Close", "Apply", "OK". The action represented by "OK" actually implies "Apply" followed by "Close". It would be nice if the dialog box instead had three buttons: "Cancel", "Apply" and "OK". Pressing "Cancel" always undoes all changes made by this dialog. Pressing "Apply" always sets any modified properties. Pressing "OK" sets any outstanding properties not already handled by "Apply", and then closes the dialog.
In fact, we ought to have instant-apply, leaving only Undo and Close, or possibly just Close.
(In reply to comment #1) > In fact, we ought to have instant-apply, leaving only Undo and Close, or > possibly just Close. > That would be inconvenient in several ways. Firstly its very uncomfortable to see instant changes, and the user doesn't feel in control. Secondly, widgets like unit spinners might end up creating a series of changes while the user tries to reach the intended value. Also, if every click resulted in applying the relevant property, even mistakes will get applied.
Tell that to the Gnome people, there's instant-apply on all manner of settings in Gnome. We'd definitely have to keep the number of changes under control, the same way we keep the number of screen updates under control by not queueing them up. Obviously undo should only apply to the final result, i.e. when the widget loses focus. Anyway, this is somewhat moot, since I have many more important things to do first. Back to the original suggestion: What happens if a user presses "Apply" then "Cancel"?
(In reply to comment #3) > them up. Obviously undo should only apply to the final result, i.e. when the > widget loses focus. <snip> > first. Back to the original suggestion: What happens if a user presses "Apply" > then "Cancel"? This is interesting ... the behaviour that I see is the same that I was thinking for the text edit mode. That's correct in a way, since both can be viewed as instances of a more abstract "modify object mode". We need a local undo stack, that can be used while the dialog box is open. Every "Apply" updates this stack, and Ctrl-Z can undo on it. If finally the user clicks OK, the stack is collapsed into a single object on the global undo stack. If the user clicks Cancel, the stack is undone and no change occurs on the object. The Ctrl-Z part will require a little planning, since the relevant Change object must also restore the PXP_NOTSET field of the property when restoring the intermediate changes. This is not too difficult, since we can use the prev/next fields to chain objects. Every "Apply" creates two objects --- one for the properties and one for the PXP_NOTSET field. The final "OK" discards the PXP objects and chains the property objects together on the global undo stack.
Your words are wise, Sameer. However, this is not something that I feel is necessary in this release.
(In reply to comment #5) > Your words are wise, Sameer. However, this is not something that I feel is > necessary in this release. Oh, but I never intended to target this at any particular release ... I just filed it as a nice behaviour to have one day. I am kinda hoping that my wanderings in the Undo system will one day fix the Properties Dialog as a side-effect. If you intend to do something similar in the text edit mode, any sufficiently generic stack related work you do will be useful here. Been thinking about this a bit more, and here's what makes sense to me: 1) Apply changes immediately. As you pointed out, this is acceptable behaviour in Gnome. Also, the dialog no longer needs to remember which properties need to be applied, thus eliminating use of the PXP_NOTSET flag. 2) The dialog now has only two buttons: Cancel, and OK. The additional interaction is (Shift)-Ctrl-Z to undo/redo local changes. 3) Since PXP_NOTSET is no longer used, it does not need a separate change object. 4) Issues to resolve: how to handle clicks on the spin button, and how to handle all the redundant changes created while the user experiments with the values. This can also fix bug #488269.
Possibly the two buttons should be Cancel and Close, but that's a minor quip that's best solved by looking in the HIG. Clicks on the spin button, undo-wise, should collapse into one change as much as possible. Updates should be queued and have an idle timer or the like come in periodically to update from the latest setting. Surely something Gnome-related has the solutions that other people have found for similar problems.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/dia/issues/221.