GNOME Bugzilla – Bug 726888
Cancel button inactive in CSV export assistent if no exportable account available
Last modified: 2018-06-29 23:28:43 UTC
In the CSV export assistent the cancel button is sometimes disabled so the user can not cancel the export. It looks to me as if the cancel button is disabled every time prev/next are disabled (because there is no valid selection of accounts to export). In Gnome shell also clicking the window close button at the top right does not do anything. IMHO the user should always be able to cancel the export. I'm attaching screenshot which shows my account "tree" (very simple) and the UI when the error occurs. (Once I select the radio button "Asset" I can see some accounts and the buttons become active.)
Created attachment 286510 [details] [review] Fixes cancel button on assistant pages This patch fixes the cancel button being disabled on some assistant pages.
Comment on attachment 286510 [details] [review] Fixes cancel button on assistant pages Hi Bob, thank you for your patch. I'm a bit puzzled with regards to what you were doing and why though. I see two independent changes: 1. there are some changes to change the default state of "Use Quotes" from TRUE to FALSE, including the same change in the glade file. How is this change related to the bug (cancel button disabled) ? 2. In the glade file you remove the "progress" page type from the Account Page only to set it again in the preparation step of the Setup Page. That second part is wrong IMO and it's a lucky coincidence it still works this way. Here's why I think it's wrong: a progress type page should only be used when the assistant has to wait for a long running process. In that case the cancel button should indeed be disabled, because the process can't be interrupted. This is not what is needed here. In this case we are waiting for user input to validate the page. More precisely the user has to select an account before he can continue. That's what a normal content page, with status complete set to FALSE provides. In that case the forward button is disabled and the cancel button is enabled. Content is the default page type in an assistant. So removing the progress type in the glade file is all that is necessary. So just the remaining question: what made you change the default value of the quotes check box ?
Oh, you don't need to redo the patch by the way, it's simple enough that I can extract the necessary parts once I understand your motivation to change the quotes check box.
The change of quotes to FALSE crept in from the other changes for quoting quotes where I decided that both export and import should be defaulting to the same, i.e. both defaulting to no quotes. The Changes to the Glade file and assistant enable the cancel button by the following... When doing an Account Tree Export, the Account page is not used and in order to make the back button work when doing an Account Tree Export this page needs to be set to progress so we step over it going backwards. When doing a Transaction Export, the Account page is used and by default is set to Content which allows the cancel button. I suppose the other option would be to have two glade files and thus avoid stepping over non relevant pages.
Thank you for the clarifications. I understand your patch better now. I have chosen to commit it in two separate commits so that each commit message can explain what the commit does. The change of default quoting style was a bit obscure in the context of fixing the disabled cancel button. As for the cancel button part of the patch - using the detour of changing the page type and manually setting the next page is a bit complicated and more importantly depends on incidental behaviour of that page type. In my opinion it is more straight forward to just delete the page you don't need upfront. Then the assistant will wire the pages cleanly together all by itself. This method still allows us to have only one glade file for both export functions. I have pushed a follow up commit that does just that which I hope will make the code easier to read when we look back in the future. With that I think we can safely close this bug. Thank you for your contribution!
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=726888. Please update any external references or bookmarks.