GNOME Bugzilla – Bug 107282
Reports execution should begin presenting the option dialog
Last modified: 2018-06-29 20:29:27 UTC
I have a big amount of transactions (about 13,500), with 700 accounts. Every time I need a report I must wait 1, 2 or 3 minutes because gnucash uses the default options to generate it. With the number of transactions I have, this signifies a big amount of time. This time ends in having an unuseful report, because the options gnucash uses never coincide with those I want to put. I consider that it would be better if gnucash presents the report options before presenting the (unuseful) report (with the default options).
I guess this shouldn't be made a default, but maybe we can come up with a preference "Open option dialog for reports first" or something like that. By default, that preference would be disabled, but for power-users like you you could enable that. However, I can't work on this ATM. As a workaround, you might want to look into the Scheme files where the reports are defined, and might want to change the default options so that they e.g. show up with zero accounts selected. For example, in src/reports/standard-reports/account-piechart.scm , this would mean changing the lines 86-88 into a single '(). I.e., instead of (lambda () (gnc:filter- bla bla bla)), the whole expression would read (lambda () '()) As I said, this should be a reasonable workaround for you.
I sent to David Hampton <hampton@employees.org> a copy of my data file, and he's going to put it somewhere in gnucash repository. David responded me: ----------------------- Thank you. I checked source file sizes in gnucash and the largest source file is 359K, while the largest sample data file is only 384K data. I'd like to check with Linas before committing a 1.1M file. Maybe we can create a separate repository so not everyone has to check out a copy of your file, but its still available for those who would like to use it. ----------------------- I invite you to test the building of some report, and see the times it tooks. Thank you!
This file is available as http://www.gnucash.org/pub/test-data/huge_test_file.bz2
I think David's suggestion is the best way to do this. Consider these two examples: (1) The Transaction Report If you open a Transaction Report (first ever in the book), you immediately get an error: No Trasactions Selected. If the Report Options dialog opened immediately upon opening the report, this wouldn't be as confusing/misleading. (2) Each time you open a book, all the reports which you had opened when you closed the book have to be regenerated---even if you have no intent of looking at them (but are keeping them up to save their settings). Christian Stimming <stimming@tuhh.de> just added code to CVS to save/restore report options. When a report is opened, the dialog could come up, taking its defaults from the options last saved. If you want to use the saved options, just click OK. I think this would be a nice improvement. Since you no longer need to keep reports open to retain their settings, any reports which were open when the book was last closed should then just use the saved settings and render without user intervention. This way, you're not bombarded with options dialogs each time you open a book containing open reports. :)
It would be better from a usability standpoint. When I first played with reports, I thought that the full report was all it can do. I thought it sucked. It took me a while to realize that I can filter it by using the options button.
Chris Shoemaker wrote: > If I understand the problem, I think the best solution is to make sure > that every report has default values that won't result in a > long-running calculation. Except that the default values of a report have to fulfil another goal as well, which may or may not conflict with the desired short-running calculation: The default options should make sure that first-time users will actually see something that is representative for what this report can actually do. If first-time users click on all reports but see "No xyz selected; go to Options dialog first" then they won't be able to get a rough idea about what this particular report does, compared to the other available reports. That's why currently the default values try to include as much as possible of the existing data. Of course there might be a compromise possible, and if it is, then even better. But I'd certainly vote against simply changing the default values so that nothing happens at all when opening the report.
another possible solution: 116565
another possible solution: bug#116565
I had written to gnucash-devel putting a bounty on this bug: US$ 100.00 for adding the possibility to present the report options before calculating the report. That'd be useful because with many accounts and many txns the account are generating in a very long time, and normally you have to customize the default settings in order to get what you want. There should be a flag control in the preferences, where the possibility to present the options before calculating any report would be set: "set reports options before calculating them", and all reports should obey this setting. The bounty is still valid!!!!
I am trying to get a report from GNU cash for my daily incoming /expenses average. As i understand there is no this kind of report. I think it is also important and you could probably work on that. Thanks
Thank you for taking the time to explain your enhancement request. The described enhancement is a good proposal and would be an advantage for the software. However, as a volunteer-driven project with limited resources, the GnuCash developers have their own priorities about the features which are most likely being worked on in the near future. In that sense, the current GnuCash developers decided not to work on your proposed feature in the next 4-6 months. In case you would like to have this feature implemented in any case, you have the following option: 1. Start to program in gnucash yourself - see http://wiki.gnucash.org/wiki/Development . 2. Convince someone who is not yet part of the GnuCash team to join the team and implement your feature. 3. Pay some of the GnuCash developers to implement your feature - ask on the mailing list gnucash-devel@gnucash.org in that case. Thank you very much. Feel free to file other bugs or enhancement requests that you find, though.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=107282. Please update any external references or bookmarks.