GNOME Bugzilla – Bug 666576
Balance Column Set Too Narrow
Last modified: 2018-06-29 23:04:00 UTC
The balance column is consistently too narrow to display an account's running balance. This occurs every time that an account is opened (e.g. on start up, as well as every time an account is opened manually as well). Although the workaround fix is simply to double click the column heading, this should not happen. I am on OS X 10.6.8, but Windows users have noted this as well.
Created attachment 207979 [details] [review] Changes behaviour of saving column widths in registers. This issue appears to be that the column width values written back to the gconf file are that of the last register page closed, so if another page has a narrower column and that page closes last it's the column width of *that* page that is saved. On next opening of GnuCash all the register pages will have width set to the saved value. Register pages appear to be closed left to right so the rightmost page column widths are saved. Making sure that the relevent register page is the rightmost tab may be a useful workaround. Proposed solution: Save the column widths when they are changed and not when the registers are closed. This would then cause all newly opened registers to have the widths of the last resize event. Not ideal (if you narrowed the column in another register page then *that* would become the default for new pages) but maybe better than current behaviour.
Created attachment 207984 [details] [review] Replace previous (malformed) patch.
While I appreciate the attention here, I don't think that this is a viable solution, really. Replacing one idiosyncratic behavior with another one isn't useful. The column widths should be by account, but I don't see how that would happen. Since window size can change between times that an account might be opened, perhaps the widths should be figured out when the account is opened. At the very least, the balance column should be optimized to display the fullest amount in an account.
Mike, thanks for looking into this. I agree with David that your proposed solution is not ideal. Some time ago, I improved a similar situation with the budgetting windows. The problem there was much worse, but the core issue was the same. What I did was to store the column widths independently in gconf for each budget (using the budget's GUID as a path). I am not 100% happy with this solution as I am not sure gconf should be used like this, but it works rather well. Perhaps you can use a similar solution for account registers, using the account's GUID as path parameter. While not 100% ideal, I think it would give a fairly good solution. Ideally (IMHO) would be to extend the config file stored per book in .gnucash/books. Presently, this ini style config file saves the visual state of the book when closed (how many windows, which pages, what was on the pages,...). Nothing prevents us from extending this file to hold information such as the column widths preferred for a given account (or budget for that matter). So next to the sections [Top], [Window x] and [Page y], there could be sections for [Account z], [Budget b] and so on. The windows and page sections only exist when a page or window was open when the book was closed, the account/budget sections could exist for each account or budget for which the columns were ever changed, so they would be more persistent. It may be more work, but I believe it would be more rewarding in the end. Of course, this is only my opinion. Feel free to implement this as you see fit.
I agree it wasn't even close to ideal, but given the manpower available... My next thought was indeed to store each register's values in .gconf with a GCONF_SECTION path variable based on *something", I hadn't yet figured out what, GUID seems ideal. But the function gnc_table_save_state (Table *table) in table-gnome.c has only *table as a parameter and I can't see how to get GUID of the account. I guess I need to get various parent widgets from Table upwards.
It's been a while... You are right that a Table object doesn't easily reveal for what it is displaying (an account register? a list of entries on an invoice ?). However the function that does call gnc_table_save_state (gnc_split_reg_ld_destroy) does know. Its only parameter GNCLedgerDisplay *ledger has got a member of type GncGUID (called leader), which refers to the account being displayed in the register. I have also searched the code to find where gnc_table_save_state is called and it appears that only gnc_split_reg_ld_destroy is calling it. So you are relatively free to change the parameters passed to gnc_table_save_state. My suggestion would be to add an extra parameter to gnc_table_save_state, calling it gconf_key (to keep it a bit generic in case the function should later be called by the invoice registers as well), and use this parameter in the gconf path to save the state. gnc_split_reg_ld_destroy could set gconf_key to the (string) value of GncGUID leader, found in its GNCLedgerDisplay parameter. What do you think ?
Created attachment 214442 [details] [review] Fix for remembering column widths. Hi Geert Time passes. Following your suggestion above, I've implemented saving the column widths in the attached patch for review. As you say the gnc_table_save_state() function is only called from one place. Reading them back however was slightly more involved as there were calls to gnc_table_init_gui from dialog_order.c and dialog_invoice.c. Luckily the note in there pointed out that the second parameter (void * data) was never used. So I changed it to gchar * and changed the callers to pass NULL for that parameter. It used to be entry_ledger, but this wasn't used. Unless I missed some good reason for it. I don't seem to have broken anything that I can see. Mike Evans
Comment on attachment 214442 [details] [review] Fix for remembering column widths. Looks good to me like this.
Comment on attachment 207984 [details] [review] Replace previous (malformed) patch. Replaced by a more recent patch
Commited to trunk as r22234
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.
As a heads up I am still seeing this bug on Ubuntu 12.04 with GNU cash version 2.4.11 Are others getting it as well on other operating systems/platforms still?
Jeff-- 2.4.11 was released 2012-07-14, just 11 days after Mike's final note (comment 11). I believe that his fixes will only appear in the NEXT release.
Ahh alrighty. He had simply said next release, so I figured that meant 2.4.11
(In reply to comment #14) > Ahh alrighty. He had simply said next release, so I figured that meant 2.4.11 Well, actually Mike had said next MAJOR release. 2.4.11 is a minor release. The next major release will be 2.6, but so far there is no release date fixed for it yet.
I could backport it to 2.4 branch but I'd like more people to test it in the development branch and give some feedback. I've only tested this on Linux myself. Testers welcome. I've just noticed though that the last unstable build, linked from http://gnucash.org/download.phtml, is dated 2010-11-21.
Where can I get the developmental source code form? Do you have snapshots or is there a SVN/GIT repo somewhere? ~Jeff
Try git svn clone http://svn.gnucash.org/repo/gnucash You might want to do a shallow clone as the entire source with history is rather large. See also: http://wiki.gnucash.org/wiki/Subversion
*** Bug 628991 has been marked as a duplicate of this bug. ***
I would like to have this bug re-opened, as the underlying problem (the Balance column is not fully displayed and cannot be obviously resized) remains in 2.6.7. Users should not have to Google "Gnucash balance column width" to figure out how to display the full balance in ANY register, EVER.
Review of attachment 214442 [details] [review]: Committed
Mike, I am glad that you supplied this patch. Thanks. But, it isn't clear to me what your latest action signifies. By recommitting, are you suggesting that the patch from 2012 fixes the problem, or that this is the best it will be? It seems to me that your patch fixes an important problem with the register (i.e., the problem of needing different column widths for different account registers). However, it didn't actually fix the specific problem with the balance column. If the balance column problem as presented initially can't be fixed, then I will see whether I can find a way to document the behavior and the workaround for other users.
I didn't re-commit I just marked the patch as committed, nothing changed in the code, just an admin thing. You're right it doesn't fix the specific problem with the balance column, it just means that next time you open the register the column widths have been preserved. Documenting the behavior is a good idea. At the time of the 'fix' there was the expectation of completely new register code which would have, probably, made the bug obsolete anyway. So please go ahead and document the double click to resize the column. Auto sizing the columns is 'a difficult problem'. Excel doesn't do it and MicroSoft have far more resources (money) to throw about. So yes 'this is the best it will be' for the foreseeable future as far I am concerned. Unless someone funds me several billion dollars of course.
Oh. OK. Thanks for the clear and rapid reply. I'll figure out where to put such a note (I am imagining right near the comment about the Description field, in section 2.3 of the Tutorial and Guide), and create a new docs bug for it.
Thanks David I'll close this again then.
(In reply to David from comment #24) > Oh. OK. Thanks for the clear and rapid reply. I'll figure out where to put > such a note (I am imagining right near the comment about the Description > field, in section 2.3 of the Tutorial and Guide), and create a new docs bug > for it. For reference: Bug 762656
Reassign version to 2.4.x so that individual 2.4 versions can be retired.
A column width was dragged by me to zero. So I can not double click the column header. How can I change the status? I don't know is it suitable for post the question here. Thank you.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=666576. Please update any external references or bookmarks.