GNOME Bugzilla – Bug 210781
Wrong OK/Cancel behavior in vfolder editor
Last modified: 2013-09-10 14:02:48 UTC
Please fill in this template when reporting a bug, unless you know what you are doing. Description of Problem: Changes to the vfolder list become effective before clicking OK. Steps to reproduce the problem: 1. Activate vfolder editor 2. Remove a vfolder Actual Results: The vfolder gets removed from the vfolder node in the tree view immediately. Expected Results: The vfolder should get removed from the vfolder node in the tree view when the user clicks OK. If the user clicks "Cancel", nothing should happen. Alternatively, we should remove the "OK" and "Cancel" buttons and only have a "Close" button, like the in the account editor.
My vote is for the "nothing happens until you hit OK" behavior. The advantage that this has over the other possibility that you propose (simply having a close button which closes the dialog when the user is done deleting folders) is that it gives the user 1) a sense of safety (nothing is going to be done until they give the OK and 2) a chance to change her mind between selecting the vFolder and closing the dialog. Another possiblity is to rename the button "Delete" or "Delete vFolders". as the macintosh human interface guideline tells us (p 206) "Whenever possible, name a button with a verb that describes the action that it performs." and further (p 207) "A user typically reads the text in a dialog box until it becomes familiar and then relies on visual cues, such as button names and positions, to respond. Names such as Save, Quit, and Erase Disk allow users to identify and click the correct button quickly. These words are often more clear and precise than names such as OK, Yes and No." So that's my 2cents.
I agree, although it contrasts with what we have in the account editor. (This inconsistency is something we might want to look at after 1.0.)
I vote for the 'only have a close button'. The other one is a lot harder to implement, but certainly possible. It doesn't delete vfolders, it deletes a single vfolder, "delete vfolders" would be gramatically incorrect. Anyway the ui is frozen, and lets see, we've had how long to figure out the button names? It was one of the first ui elements written. (i'm not referring to the immediate-update behaviour, which has changed).
Marking as 1.0 to make sure this doesn't slip through the cracks.
I am pretty sure we had the ok/cancel behavior implemented already in the early days though... And it was changed recently, introducing this inconsistency.
Yeah it was, but the code changed. Like a lot.
I've removed the cancel button. There's preliminary code that undoes the changes with a cancel button that can be enabled with EVOLUTION_RULE_UNDO=1 But it doesn't entirely work yet. Marking 1.1 Although apoarently teh whole filter dialogue is fucked and is supposed to need rewriting anyway so who cares?
Because of the decision to remap 1.1->1.2 and 1.2->1.4, I'm going to be moving a large number of bugs around in the bugzilla. You can just search on 'body contains' 'Because of the decision to remap' and mark all as read. Please direct all questions about this change to evolution@ximian.com, not the bug. Luis
Created attachment 41340 [details] [review] a fix
Adding patch keyword
applied