GNOME Bugzilla – Bug 343227
Grand total bar in the bottom showing null elements in the drop down list
Last modified: 2018-06-29 21:05:43 UTC
Main accounts window: when I click on the grand totals etc. bar on the bottom, a dropdown list is shown with 4 void lines in the upper parts. I must click on the arrow on the bottom of the list in order to see the elements of the list which stay in the bottom part of it.
Are you able to reproduce this with 2.0.x or later?
Yes, it's active, I think it's related to foreign currencies: When I click on the bar, only two lines are shown and the expanded element has many blank line above those. Scrolling up, other lines appears with the same values in the foreign currencies I am using. You can reproduce it, creating in a new file various accounts with different currencies. A screenshot with 3 accounts is added.
Created attachment 86768 [details] 3 accounts, grandtotal bar shows empty lines
I'm unable to reproduce with a new file with accounts as indicated in the screenshot, even after saving/reloading, using trunk@15967. What locale? What are the settings in {Edit > Preferences > Accounting Period > Summarybar} and {Edit > Preferences > Accounts > Default Currency}?
> I'm unable to reproduce with a new file with accounts as indicated in the > screenshot, even after saving/reloading, using trunk@15967 Maybe the window magnitude has something to do with that. I can see the bug if the window is magnified, but I can't see it if the window's high is smaller. I have screen 1024x768 resolution. It doesn't depend on the window width. > What locale? > What are the settings in > {Edit > Preferences > Accounting Period > Summarybar} I don't have the Summarybar preference > and {Edit > Preferences > Accounts > Default Currency}? USD
still a problem in the latest 2.2.x versions?
Created attachment 113148 [details] Screeshot
yes, but I think it's a gtk problem or decision
Thanks for reporting back. I cannot reproduce this on r16997, but I will leave it open and update the version field. What version exactly are you using?
This is present in 2.6.3 on Linux, when the window is maximised. It is not present on Windows (either maximised or normal window), neither on Linux when the window is not maximised. It seems like a gtk issue.
Created attachment 294860 [details] [review] Account Summary bar alignment What you see can be traced back to this GTK bug 72695, the space is there to allow the scrolling of the options when the selected option is at the top of the list. The GTK bug goes into it in more detail with various options discussed in bug 129463 with both bugs marked as RESOLVED, FIXED. While investigating this I did notice that the alignment of the text was not consistent and so have created a patch to correct this.
Comment on attachment 294860 [details] [review] Account Summary bar alignment Hi Robert, thank you for your patch. Unfortunately I'm having some difficulty understanding which problem you are trying to solve. You state the alignment is not consistent, but on my own installation of gnucash 2.6.5 and master it does seem to be consistent: every column in the list is nicely left-aligned. How is this on your system ? Your patch adds complexity for the user by making an option to choose between two different alignment styles. What alignment would you prefer ? If that's a sane alignment scheme we should just implement that and skip the options. Thinking of it I see one potential minor improvement: I would keep the descriptions left aligned at all times. It may be nice though if the amounts become right aligned like this: Net Assets: $ 1125.00 Net Assets: $ 75.00 Net Assets: C$ 1050.00 As opposed to how it is aligned now: Net Assets: $ 1125.00 Net Assets: $ 75.00 Net Assets: C$ 1050.00 However that scheme would break for currencies that actually print the currency behind the amount or with negative amounts. I'm interested to hear your view on this.
Created attachment 295465 [details] Screen shot of summary bar, old and new The attachment shows the summary bar three times, master, new wide and new central. As you can see there is misalignment on my VM setup with master, I also get it on my live Linux version 2.6.4 and that was what I was trying to improve. In the old setup, the width was split into 5th's with each part of text being left or right aligned. With the new setup it is 3rd's and a cell data function combining the elements with left, centre and right alignments. Which one I prefer, probably wide with maybe a bit more space at the edges, the preference option was an after thought. I do not know how often one actually uses this menu, I don't, it is left on grand total so the complexity to get further text alignment may not be worth it as on normal operation you only see one line.
Created attachment 295894 [details] [review] Summary bar patch version 2 This patch aligns the text in the account summary bar so all text is inline. The bar is split into three and each part is aligned centraly and on the popup it is aligned to the left.
Created attachment 295895 [details] [review] Summary bar patch version 3 After some pondering, this patch aligns the text in the account summary bar so all text is in line. The bar is split into three and each part is aligned centrally and on the pop up it is aligned to the left but with the decimal points aligned vertically. This patch needs to be applied on top of second patch, I am not sure if it looks better but resembles your suggestion.
Created attachment 296326 [details] Illustration of negative number misalignment Hi Bob, thanks for the updates. Both give nice visual results. As you might have guessed I particularly like the layout as created in version 3. That's clever thinking. On the other hand I worry slightly about the required change to a monospaced font. To me this is like fixing one design issue (misalignment) by introducing another one (inconsistent font use). There is also one misalignment still in version 3 if negative numbers enter the mix and the negative sign is at the end (see screenshot). In that case the width calculation should start from an absolute value. And I *think* gnucash would even support negative numbers being denoted as (123.00) if the OS uses this. Which you would have to treat as if the negative sign was in front of the value. These misalignment issues can be fixed no doubt. The font issue however will be much more difficult. So I'm inclined to stick with your version 2, which also gives a nice and clean visual result. That is unless you really want to search for a solution that doesn't require a monospaced font. But if you are happy with version2, I am certainly as well.
OK, Leave this one open and I will have a further ponder. I will update if I have some thing or can not find a solution.
OK, I had forgotten about this but can not think of a better way, so this can be closed,
Closing as per request
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=343227. Please update any external references or bookmarks.