After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 666576 - Balance Column Set Too Narrow
Balance Column Set Too Narrow
Status: RESOLVED FIXED
Product: GnuCash
Classification: Other
Component: Documentation
2.4.x
Other Mac OS
: Normal normal
: ---
Assigned To: Christian Stimming
Geert Janssens
: 628991 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2011-12-20 08:01 UTC by David
Modified: 2018-06-29 23:04 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Changes behaviour of saving column widths in registers. (1.42 KB, patch)
2012-02-19 14:50 UTC, Mike Evans
none Details | Review
Replace previous (malformed) patch. (1.42 KB, patch)
2012-02-19 15:30 UTC, Mike Evans
needs-work Details | Review
Fix for remembering column widths. (7.24 KB, patch)
2012-05-19 15:17 UTC, mike
committed Details | Review

Description David 2011-12-20 08:01:54 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.
Comment 1 Mike Evans 2012-02-19 14:50:55 UTC
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.
Comment 2 Mike Evans 2012-02-19 15:30:31 UTC
Created attachment 207984 [details] [review]
Replace previous (malformed) patch.
Comment 3 David 2012-02-20 06:35:27 UTC
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.
Comment 4 Geert Janssens 2012-02-20 14:44:01 UTC
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.
Comment 5 Mike Evans 2012-02-20 15:39:48 UTC
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.
Comment 6 Geert Janssens 2012-05-11 16:34:31 UTC
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 ?
Comment 7 mike 2012-05-19 15:17:17 UTC
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 8 Geert Janssens 2012-06-22 14:49:23 UTC
Comment on attachment 214442 [details] [review]
Fix for remembering column widths.

Looks good to me like this.
Comment 9 Geert Janssens 2012-06-22 15:14:23 UTC
Comment on attachment 207984 [details] [review]
Replace previous (malformed) patch.

Replaced by a more recent patch
Comment 10 Mike Evans 2012-06-23 12:26:17 UTC
Commited to trunk as r22234
Comment 11 Mike Evans 2012-07-03 08:10:32 UTC
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.
Comment 12 Jeff Hoogland 2012-10-08 22:25:40 UTC
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?
Comment 13 David 2012-10-08 23:21:45 UTC
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.
Comment 14 Jeff Hoogland 2012-10-09 00:49:49 UTC
Ahh alrighty. He had simply said next release, so I figured that meant 2.4.11
Comment 15 Geert Janssens 2012-10-09 09:42:06 UTC
(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.
Comment 16 Mike Evans 2012-10-09 10:58:11 UTC
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.
Comment 17 Jeff Hoogland 2012-10-09 14:06:36 UTC
Where can I get the developmental source code form? Do you have snapshots or is there a SVN/GIT repo somewhere?

~Jeff
Comment 18 Mike Evans 2012-10-09 14:18:57 UTC
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
Comment 19 Geert Janssens 2014-08-25 10:31:49 UTC
*** Bug 628991 has been marked as a duplicate of this bug. ***
Comment 20 David 2015-09-02 19:40:52 UTC
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.
Comment 21 Mike Evans 2016-02-01 13:23:03 UTC
Review of attachment 214442 [details] [review]:

Committed
Comment 22 David 2016-02-03 16:29:19 UTC
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.
Comment 23 Mike Evans 2016-02-03 20:01:31 UTC
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.
Comment 24 David 2016-02-04 04:11:46 UTC
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.
Comment 25 Mike Evans 2016-02-23 15:48:27 UTC
Thanks David I'll close this again then.
Comment 26 David 2016-02-25 01:54:35 UTC
(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
Comment 27 John Ralls 2017-09-24 22:45:56 UTC
Reassign version to 2.4.x so that individual 2.4 versions can be retired.
Comment 28 gorf 2018-01-25 04:09:06 UTC
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.
Comment 29 John Ralls 2018-06-29 23:04:00 UTC
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.