When tinkering with report options, and then clicking "Apply" to witness your changes, the "OK" button becomes disabled and the user must use the "cancel" or window close "X" in order to get rid of the options dialog box. This behavior is confusing to the user. IMO, "Apply" should allow the user to witness changes, finally accepting the changes using "OK" or aborting the changes using "Cancel". Other information:
Yeah, this is annoying. Confirming, changing to RFE.
Another case: if you click on Default in error, your original settings would be irretrievably lost if there is no way to Cancel an action. Apply == change the settings and do not close the window (let me change other settings) OK == accept the changes and close the window Cancel == change nothing and close the window
I don't see this behaviour anymore in gnucash 2.6.11. 1. There no longer is a "Default" button, so the use case in comment 2 no longer applies. 2. When I make changes to the report options and hit apply, the ok button remains active and can be clicked to close the options window. Note that when you hit apply, any changes are performed. So clicking cancel afterwards will not revert to what you had *before* hitting apply. I believe this is reasonable behaviour though. If you still see this issue, please feel free to reopen this bug report. Thank you.
I was wrong. For some reason it sometimes keeps the ok button enabled and sometimes it doesn't. Reopening for further investigation...
*** Bug 683532 has been marked as a duplicate of this bug. ***
Geert, Do you have an opinion on whether the OK button should always be clickable ? Currently.. Open Report Options, Cancel - clickable Apply - not clickable OK - not clickable make a change, All become clickable Click Apply, Cancel - clickable Apply - not clickable OK - not clickable Note: there is a 'Reset defaults' button and once clicked, All become clickable Also note this dialog applies to 'File->Properties' and also 'Edit->Style Sheets'
The intent of changes in active state of the buttons is to give visual feedback to the user on whether or not there are option changes in the dialog that have not been applied. There are plenty of angles to approach this from. First the "Apply" button. Disabling the "Apply" button if there are no pending changes is a visual clue to the user so that may be useful. On the other hand just clicking the "Apply" button if no changes were made is effectively a non-operation from the user's point of view and hence harmless. In that sense once could argue there's not much point in disabling it or even that it's needlessly restricting the user's choices. The "Ok" button can be interpreted in different ways. In this particular context sense "Ok" really means "Apply & Close". If there are no pending changes the "Apply" part of this meaning could be treated as the single "Apply" button above. There is however also the "Close" aspect of the button. The user should always be able to close the dialog. So for the "Ok" button I do agree with the original posters it should never be disabled. Either there are no changes and it works as a simple close action, or there are changes and they will be applied before the dialog is closed. However if we stop disabling both "Apply" and "Ok", there"s no longer any visual feedback on pending changes. So we would lose something useful. That finally brings me to the "Cancel" button. As the "Ok" button this is also a double-action button, namely "Undo changes & Close". Note that the "Undo changes" part only reverts back to the last Applied state which is not necessarily the state when the dialog was opened. Building on that, if no changes were made since the last applied state "Cancel" is really reduced to "Close". To keep some form of visual feedback to the user I would propose to effectively change the button's name to indicate the dialog's state: if there are pending changes, the button would be named "Cancel", if there are no pending changes, the button would be named "Close". On could do the same with the "Ok" button instead. However to me a "Cancel" button next to a "Close" button not actively cancelling something is more confusing than an "Ok" button that just confirms the unchanged state next to a "Close" button. So in short here's my suggestion: Ok and Apply: always active Cancel: name it "Cancel" or "Close" based on the presence of pending changes. By the way, the "Reset defaults" button when clicked can effectively generate pending changes, hence it did enable all buttons (state changes towards default). However there's a minor paper cut bug in there as well: it will *always* enable the buttons (or in other words make pending changes) even if all options already were in their default state. That should not happen.
Geert, Thanks for the insight, not sure why I did not think about changing the button labels. I think I may try and change the OK button so that it is always enabled but the label will change from 'OK' to 'Close' based on if changes have been made and also change the sensitivity of the Cancel button to something like.. Open Report Options, Cancel - notclickable Apply - not clickable Close - clickable make a change, All become clickable, Close renamed to OK Click Apply, Cancel - not clickable Apply - not clickable Close - clickable Will also look at the 'Reset Button'
I have gone with Geerts idea of conditionally changing the text of the cancel button from Cancel to Close as it looked better and effectively did the same thing but have left the apply and OK buttons as is. Also fixed the reset button so it does not enable the OK/Apply buttons when the values are already set to default.
