GNOME Bugzilla – Bug 795471
Impossible to Edit Budget Unless Maximized
Last modified: 2018-06-30 00:08:48 UTC
After upgrading to GnuCash 3.0, any budget cells "right of the fold" are impossible to edit. This means I am only able to budget the first few months, after which scrolling to the right and selecting any cell causes the view to snap back to the left. Based on my testing, it is still possible to key a value while the cell is not visible, but this is not a practical workaround. By maximizing the budget window, all cells become visible and it is again possible to edit the budget. This is the only good workaround I've found. This also means the window is basically useless when restored to its default size.
Possible fix in PR343
This problem has been fixed in our software repository. The fix will go into the next software release, 3.1. Once that release is available, you may want to check for a software upgrade provided by your Linux distribution or on our website.
This is not fixed. In GnuCash 3.1, I can now select and edit exactly one cell. Upon pressing the Enter key, the Account Name column resizes and consumes nearly the entire window if not maximized. To edit another cell, I have to first resize the Account Name column or maximize the window. This is quite broken.
I have just tried the Windows 3.1 download and my Linux VM and do not see this. I have a test budget and I can enter a value in a cell close to the accounts column and press return or enter with no column resize. If I reduce the Gnucash window size so I get a horizontal scroll bar and try to enter a value in one of the furthest columns with return or enter I still do not see what you are experiencing.
I will test more tonight. Perhaps there is an extra step or a specific clicking pattern that still causes this for me.
Here are more details about the experience with this feature. When I open my budget, the default width for the Account Name feature is appropriate for a maximized window only, but I normally run GunCash at less than half screen. I get an available horizontal scrollbar, but I do try to avoid it because it pushes the account names out of view. The behavior I want is to see a narrow Account Name column, so I drag that divider to the left before editing. If I DON'T change the width of the Account Name column and instead use the scrollbar, there are no additional problems. However, as soon as I fix the column width and edit a cell, that cell is again pushed out of view and becomes a seriously painful navigation experience. As in previous versions, I expect to find one or more workarounds for the unwanted column width itself. In GnuCash 3.1, it is adequate to do this: 1. Resize the Account Name column. 2. Immediately close the budget. 3. Reopen the budget. This is really nice because I don't have to dig into the user files and hack on them with a text editor as in older versions. However, again, this all falls apart as soon as I maximize and restore the window. I then have to re-apply this workaround just to be able to edit my budget again.
OK, I see what you mean, if you start with a wide account column and drag it smaller and then make entry it pings back. I think the reason for this is when you make it smaller, the space is added to the total column to compensate as the table width does not shrink. Will see if that is by design or fixable.
I second this bug. This seriously impairs working with budgets. The behaviour is such that the accounts column gets auto-resized to extremely wide and one or two columns on the right (i.e. Totals and maybe one or two next to it) gets pushed out to the left. So you have a screen with huge white space in the middle and your work-cells (i.e. the accounts - which you may need to see are far on the left and the totals plus one to few months are out in the right). This persists after resizing the window and re-opening the budget. If I double click on the accounts column border then the budget columns get pushed to the left, but the Totals column still stays extremely wide - hiding its numbers past the right border. It is as if the Totals column has no awareness of how wide the window is and how much space it has. Also after every entry into the budget value, the bodget columns snap back to the right - i.e. we again get huge whitespace in the middle. It would seem that a solution could be to make GnuCash to *respect* the *width* of the Accounts column that has been *set by user* and for the Totals column to always be visible (unless the number of period columns is too large). A nice (and perhaps easy) feature helping with this beaviour could be to shade the totals column light grey, so that it would be visually different. Then it would be immediately clear if the numbers it contains are fully visible or not. Otherwises sometimes it is hard to tell with all the scrolling when one is thinking about the budget too. In any case - thanks for the great program, it is great and necessary.
Hopefully the last issue is fixed in PR 359
Yup. Every time I open my budget, I have to resize all columns so it is usable. Even then, the totals column is so close to the right edge that I cannot see the entire total. User-resizable columns (and padding on the totals column) could make this budget screen a lot more usable. As others have commented - awesome budgeting utility, just needs a bit of love and polish. Thanks guys.
What version are you using, look at help->about build id, default column size is set by the header date width and should increase if numbers get too big so why do you need to change it ?
Hi Bob, Version: Version: 3.1 Build ID: 3.0-118-gd2ef5fd0f+ (2018-04-28) I have the option to see the first column, or the last column, but not both. With columns fit correctly with Account Name fully visible, I then must scroll about 8" to the right in order to read the right-justified totals column. The TOTAL header is fine, but the right-adjusted values believe that the screen is maximized. It appears that the report dimensions are set at program start and ignore any resizing information that happens later. Just now I shutdown and restarted GNUCash and the columns adjusted to the new dimensions. However any change to column width and it reverts to the totals column being right-justified against the "full_screen_dimension + 2" right so I must now scroll about 8" right to see totals again. The solution so far is to resize the window and columns just right, estimating the width of the Total values (which are 8" away to the right) and then restart the program in order to see all columns concurrently. If I then maximize the window, the values of the TOTALS column are again right-justified about 8" to the right of the window edge. I can work with it, with a bit of restarting the app, but it is still a bug.
My budget changes were committed on the 28/5/2018 so after your build which should fix your problem. The only resizeable column is realy the account one, all the other ones are fixed width to start with based on the width of the date header. The account width should be saved. If you have a lot of columns, then yes you will have a scrollbar and unfortunately you will not be able to see the account column and the total column, I did think of a possible way but that would require more time and not relevant to this bug. I think there will be another release shortly so that will include my changes.
To be clear, the problem is not that my screen is too small... just that the totals column is prefixed by up to 8" of whitespace because it is using dimensions of my full-screen, not my current dialog size. That said, thanks for reviewing.
Since you're on Windows please try https://code.gnucash.org/builds/win32/maint/gnucash-3.1-2018-06-18-git-3.1-171-g1e3a44500+.setup.exe to see if Bob's work does in fact fix your problem.
Installed from that link. Version now reported as 3.1, Build ID: git 3.1-171-g1e3a44500+ (2018-06-17) Maximize & restore now works with budgets. Resizing the account name column prior to maximize causes the Total column to grow upon maximize, whereas when I didn't touch the columns it was the Account Name column that grew. While this is a bit ugly, it is not the same problem reported by James above. Resizing the account name column prior to restore gives sensible results. I would call this overall imperfect but much better, and finally usable.
Additionally, closing and re-opening the budget causes the maximize behavior to revert to growing the Account Name column again. /shrug
No <<shrug>> required - this is a spectacular success. Functions exactly as any spreadsheet would. Of course one column must be wider - but that is fully expected behavior. Great work and quickly done! Thanks. OK to close from my end.
By default the account column is the expand column but if it is manually changed this will reset to the last column. If Gnucash is maximised in this state, the totals column then has a lot of white space so this change reapplies the expand setting to the account column so that it has the extra space. As the tree view is a fixed width based on the size of the Gnucash window, at least one column has to expand to take up the extra space so this change will make it more consistent to be the account column. If the account column is made smaller, hence the totals column is expanded and the budget is updated the view will change back to the account having the extra space. I can see no reason why you would not want this. If the account column is made larger and you have a scrollbar, this setting will be maintained. The width of the account column will be saved and restored as normal. Also added some padding to the numbers so they are separated from the next more clearly. All this is in PR 375 yet to be approved.
PR 375 is committed. Thanks, everyone.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=795471. Please update any external references or bookmarks.