Using customized reports in the 2.6 series

[Geert Janssens]

On Saturday 10 January 2015 11:30:47 David Carlson wrote:
> Last night I was experimenting with fixing an existing custom report
> by adding some missing new accounts and my dog jostled my arm as I
> was clicking on something which moved the curser across one of the
> Save buttons as I was pressing the mouse button.  I was not ready for
> that and it seemed that it went ahead and saved without any
> confirmation click.  Worse, if I clicked Save Report Configuration
> As.. multiple times (as in fat fingers or cat on the keyboard), it
> would merrily add a digit to the end of the name and increment it and
> save multiple times without pausing to give me a chance to actually
> change the name or cancel out.

Hi David,

I have just tried this on my linux box and my experience is partly different:
When I hit the Save as button the Saved Report Configuration window pops up, and the newly 
added report's name is highlighted. I can immediately start typing a different name to rename 
it. So there is a change to change the name right there.

It's true you can't cancel adding the new report. I considered this less important when I rewrote 
this dialog because the button to delete a report is right next to the report name. So for user 
interaction there is little gain in yet another cancel button. And from a developer perspective it 
would complicate the code even more.


> I found several new custom reports
> that I had not saved in the form that I wanted.
> 
> Continuing, I had to experiment to figure out that one of the three
> little icons to the right of each report name (if the window was wide
> enough to see all of this) would delete it's respective report (I
> think).
Several issues here:
- the fact that you had to experiment suggests these buttons aren't documented. If that's so 
you have hit a documentation bug. Can you report this in bugzilla please to keep track of it ?
- I never used report names that long that they are pushing the buttons out of sight. I just tried 
and indeed this can happen. That is a usability bug which you can report as well.
- Did you see the tooltips for the little buttons while hovering them ? On my system they explain 
what each button does.

> Again, I think there was no confirmation to verify that I did
> not have a problem with a touchy mouser button.

There definitely is a confirmation prompt on my system. It will ask whether I really want to 
delete the report.

> Then I needed to
> delete the extra digits at the end of the saved name to change it to
> the name that I really wanted, and there was no Done key once I
> changed the name.  I guess this may be emulating the way Android
> stuff works, but it is really out of place on a PC in a program that
> otherwise behaves far differently.
> 
This is not emulating how android works at all. The name changing concept is based on how it 
works on your file manager. Windows Explorer, Konqueror, Apple's Finder, Dolphin,... they all 
behave like this: you get to change the name and to confirm the change you hit enter or click 
on a different line.

That was the whole idea behind the rewrite of the saved reports window. To make it behave 
more like managing files (although the saved report configurations are not really files). It's not 
completely mimicking a full file manager due to several reasons (there are no real files to 
manage, so only parts of the metaphor were used).

> There is no help in either manual about this stuff yet, except a note
> that it needs to be added.
> 
That confirms we have a documentation bug here.

> After all of that, GnuCash decided to hang, and I had to force close
> it with the Windows Task manager, so I am not sure what made it hang.

Hmm, that certainly adds to the frustration... Sorry to hear that.

>  This morning I re-started GnuCash, and I found that the report
> window had not been updated after all.

I'm not sure what you are trying to explain here. But I guess this is normal. The saved report 
configurations are independent of the saved state of your open reports. The exact state of your 
open reports is only saved to disk if gnucash closes normally (or more exactly the book closes 
normally). Due to the crash you experienced, the next time you open gnucash it will only know 
the state of the reports from before your last gnucash run and so it won't know that you have 
saved changes for one open report in a new saved report configuration.

The saved report configurations which you can open via the Reports menu *are* saved each 
time you make a change to one of them. So after a crash these are up to date right up until the 
crash.

This synchronization failure is unfortunately unavoidable given the way the report system is 
currently implemented.

Your best way out is to reopen the wanted saved report configuration and close the report that 
was open, but now with out of date information.

> Further, the report menu now
> calls the list of custom reports "Saved Report Configurations" now to
> open a listed report,

The name change is deliberate. The word custom report had way too many meanings and 
caused confusion when being asked about. Similarly "Saved Report" has multiple meanings as 
well unfortunately. I originally chose the name "Report Presets" to avoid these old ambiguities, 
but others didn't like because it would be confusing in yet another way :(

So eventually I ended up with the long winded "Saved Report Configurations", which is different 
from everything we used before as name and clearly indicates it's only about the configuration 
that is kept for future use not the full report. That difference is important because we call the 
html files we export "Saved Reports" as well...

> one has to either click on one of those little
> icons next to the title or click on the title, but not accidentally
> click on either of the two other icons, which is easy, as the curser
> can cover two at once. The last custom report name change had stuck
> and that the last saved configuration did have the changes.

You can also double-click the title to open a report. That avoids mis-clicking a button completely.

I'm surprised to hear though that the cursor is big enough to cover two buttons. Still this may 
be something to reconsider. It sounds like the new window needs some revision on accessibility.

In any case, thanks for the feedback :)

Regards,

Geert