QGIS » QGIS Application

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.

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...

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.

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.

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...

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?)