Bug report #4092

Cancel, OK and Apply buttons behave incorrectly and inconsistently in "Settings>Project Properties"

Added by Alister Hood over 9 years ago. Updated over 1 year ago.

Status:Closed
Priority:Low
Assignee:-
Category:GUI
Affected QGIS version:master Regression?:No
Operating System: Easy fix?:No
Pull Request or Patch supplied:No Resolution:end of life
Crashes QGIS or corrupts data:No Copied to github as #:14075

Description

e.g. change the CRS or the on-the-fly transformation setting, click apply, then click cancel. When you click cancel it should revert to the previous setting, but it doesn't. (If this was actually the intended behaviour then the OK button should really be labelled "Apply and close")

e.g. change the Selection colour, click apply, then click cancel. In this case too, when you click cancel it should revert to the previous setting, but it doesn't.

e.g. change the Background colour and click apply. The change is not applied. Click OK. The change is still not applied. Open the project settings again, change the colour again and OK. The colour you changed it to the first time is applied. Open the project settings again, change the colour again and click apply. The colour you changed it to the second time is applied. Click cancel. The colour stays the same. So in this case 1) the cancel button does nothing, and 2) both OK and cancel use the previous change to the setting, not the current change.

e.g. change the Project title and click apply. Nothing happens. Click Cancel. The title is changed. So in this case 1) the cancel button does not revert the change, and 2) the Apply button makes the change, but does not apply it.

Also see similar bug #3761 for the symbol properties dialog

N.B. I am using Trunk on Win XP if that matters.

History

#1 Updated by Alister Hood over 9 years ago

  • Category set to GUI

#2 Updated by Giovanni Manghi almost 9 years ago

  • Target version set to Version 1.7.4

#3 Updated by Paolo Cavallini over 8 years ago

  • Target version changed from Version 1.7.4 to Version 1.8.0
  • Affected QGIS version set to master
  • Crashes QGIS or corrupts data set to No

#4 Updated by Paolo Cavallini about 8 years ago

  • Target version changed from Version 1.8.0 to Version 2.0.0

#5 Updated by Jürgen Fischer over 6 years ago

  • Target version changed from Version 2.0.0 to Future Release - Lower Priority

#6 Updated by Médéric RIBREUX almost 5 years ago

  • Pull Request or Patch supplied set to No
  • Status changed from Open to In Progress

Hello, bug triage...

When you click cancel it should revert to the previous setting, but it doesn't. (If this was actually the intended behaviour then the OK button should really be labelled "Apply and close")

I do not agree with the "Apply" behavior you are describing. In my opinion, apply is made to apply the configuration to see the changes you've made without closing the configuration window because you need to change something more or you are not sure about your choice. Once applied, the configuration can't be canceled because it has already been applied and this is the new reference configuration project. Cancel button is just there to cancel modifications that have NOT been already applied.

This behavior can be met in nearly every QGIS dialog box that involves Ok/Cancel/Apply (try the style tab for example).

To my mind, we need to keep this behavior as it is. But here are some things to go further on this bug:

- Project CRS is applied immediately (Good).
- Selection color is applied immediately (Good).
- Background color is applied immediately (so it's good now).
- Project title is only displayed after closing the configuration window (which is bad: should have been modified when Apply button is clicked).

To fix this bug, it seems now that we just need to fix the immediate application of the project title (which is the main QGIS window).

What do you think about this ?

#7 Updated by Alister Hood almost 5 years ago

https://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/OSXHIGuidelines/WindowDialogs.html#//apple_ref/doc/uid/20000957-CH43-SW3
Ensure that Cancel undoes applied changes...

https://developer.gnome.org/hig-book/unstable/windows-utility.html.en
Cancel
Resets all settings in the window to those that were in force when the window was opened. Note: this must undo the effects of all applications of the Apply since the window was opened, not just the most recent one.

https://msdn.microsoft.com/en-us/library/windows/desktop/dn742479(v=vs.85).aspx
Label a button Cancel if canceling returns the environment to its previous state (leaving no side effect)

I was having trouble finding any guidance for KDE, but these three all agree on what Cancel should mean.

#8 Updated by Médéric RIBREUX almost 5 years ago

Hello,

thanks for the guidelines, that's a good external reference.

You made me doubt about it so I tried some other applications... And actually a lot of the applications that I use everyday have the same behaviour than QGIS for Apply/Cancel buttons (Outlook 2003/Clementine/Wireshark/etc.). Even Windows 7 file explorer can't cancel an applied configuration. It is the same for Google Earth. That's why I thought Cancel should not cancel an applied configuration.

Ok, so we also need to find a way to backup the configuration of the project settings at the opening of the dialog box in case the user click on Cancel...

#9 Updated by Jürgen Fischer almost 5 years ago

Médéric RIBREUX wrote:

You made me doubt about it so I tried some other applications... And actually a lot of the applications that I use everyday have the same behaviour than QGIS for Apply/Cancel buttons (Outlook 2003/Clementine/Wireshark/etc.). Even Windows 7 file explorer can't cancel an applied configuration. It is the same for Google Earth. That's why I thought Cancel should not cancel an applied configuration.

Did you find any application which behaves the other way? I don't recall to have encountered any and if I had I would probably considered it a bug.

#10 Updated by Alister Hood almost 5 years ago

It used to be a standard which was widely followed, at least on Windows - that's why I expected it to work like that when I filed the ticket.

There seems to be a campaign by both Gnome and Microsoft to do away with both apply buttons and cancel buttons, so they are more difficult to find now, especially both together. They prefer to make dialogs with only one button ("close" or "OK"), and make everything apply instantly, so once you start changing things in a dialog there is no way of cancelling them, even in the case without an "apply button". I've seen some very angry blog posts about how stupid this sort of design is :)

In a quick search the first current example I found that uses Cancel buttons correctly is the Gimp (e.g. in the preferences dialog), although it doesn't have an apply button as it is "instant apply". Interestingly it also has a "reset" button which does the same thing as "cancel", but leaves the dialog open. I rather like this behaviour :) Interestingly the dialogs I checked in Libreoffice also have the "reset" button even though they aren't "instand apply" and don't have an apply button.

#11 Updated by Alister Hood almost 5 years ago

I've seen places in Windows 10 where there are both "apply" and "cancel" buttons and they don't follow the standard. Instead the cancel button starts out disabled, then when you change something it is enabled, and when you click it it is disabled again. This is the only behaviour that would make sense if Cancel doesn't undo "applied" changes, but it is less useful, and means that in dialogs with Apply buttons Cancel would behave differently to any dialogs that were "instant apply", if these had a Cancel button to undo the "instant applied" changes and close the dialog...

#12 Updated by Giovanni Manghi over 3 years ago

  • Easy fix? set to No
  • Regression? set to No

#13 Updated by Alister Hood almost 2 years ago

  • Priority changed from Normal to Low
  • Description updated (diff)

The bug with applying the background colour has been fixed, so it seems that the behaviour is generally consistent now (even though I don't agree with it ;) ), although I haven't thoroughly tested everything.

However, this is still true:

change the Project title and click apply. Nothing happens. Click Cancel. The title is changed. So in this case 1) the cancel button does not revert the change, and 2) the Apply button makes the change, but does not apply it.

I assume there is no technical reason why the apply button can't instantly apply this change...

#14 Updated by Alister Hood almost 2 years ago

Description updated

Redmine is lying - I didn't touch the description! I've seen this before; maybe it is some kind of automatic invisible whitespace change (perhaps line endings?)

#15 Updated by Giovanni Manghi over 1 year ago

  • Status changed from In Progress to Closed
  • Resolution set to end of life

Also available in: Atom PDF