This seems to be OS specific. On macOS 10.13.4, the scroll bar is just a sliver and it fits in to the right of the check boxes.

It's like that on linux as well until you hover over it with your mouse. That will widen it to be used. However at the same time it will cover the tick boxes.

I see the same behaviour on my Windows test box by the way. Though with the custum (ugly) theme I configured there it behaves slightly differently in that the scrollbar is completely hidden by default and slided into view when hovering the area.

Note this also illustrates the weakness of the proposed solution on the mailing list. The amount of additional whitespace required to cater for the scroll bar is highly theme dependent.

I think the more elegant solution is to make the last column expandable instead of the description column and allow columns to be autosized by double-clicking the divider between the two. And then just leave it up to the user to set the column sizes the way s/he likes.

There are style sheets?
So long as the default style works OK I'm happy.

A simpler solution is to disable the overlay scrollbars for this window then the scrollbars appear like the register. The columns can already be resized, just drag the left divider of the 'Amount' column.

I would imagined with your changes someone will raise a request to have the column widths saved, just a thought.

Hmm, it's all a bit clunky. I'm not too fond of fixed scroll bars. They are out of place with the rest of the theme if that uses the dynamic scrollbar and it will also be there even if there are not enough lines to require one. That could be coded around but at some point we're almost recoding a scroll bar.

You're right that my proposal is equally crippled.

So I'm revisiting one of the other suggestions you made in your mail: change the column order. Is there a strong reason to keep the tick box the last column other than that it's always been that way ?
From a ux point of view it seems to me it could just as well be the first column. That's congruent with how tick boxes are typically used: in front of the option they will enable/disable. Moving it there will have two positive side effects:
1. it solves the issue this bug represents as the widening scroll bar would now partly cover the amount column. This is much better because there's no competition for mouse activity between that column and the scroll bar. If the mouse is there it's likely the user does want to scroll at which point the exact amount is less important.
2. The amount column will be slightly aligned better with the total amount below the tree view (although there's still room for more improvement there).

Any thoughts on this route ?

In testing the scrollbars do disappear when not required but I like moving the reconciled column to be first. So along with tweaking the total amount to align better is it worth removing the 'set_transient_for' setting, its already a window so should not cause any warnings ?

I think that's a good idea as the transient assignment is interfering with the "Jump To Transaction" feature. Do make it a separate commit though please.

Changes made in PR339

This has been merged. The fix will appear in gnucash 3.1 (to be released).

Thanks Bob!

Loaded 3.1 and it works OK on my Windows setup. "jump to Transaction" feature now works again as well.
Many thanks for your efforts.

Just tested using 3.1.2 on MacOS 10.13.4. While the checkboxes no longer are covered by the scroll bar (it seems this *did* happen for me on hover, but not using the scroll wheel) because of their placement as the first column, this has the ?unintended? effect of sorting the transaction list by if the box is checked. So checking an item moves it to the bottom of the list. Trying to look over transactions and checking them off has them jumping around the screen. I'm not sure if this should be considered 'not fixed', 'needs work' or a 'new bug.'

Thanks for the feedback. I consider this "not fixed".

You can work around it by clicking on the Date column header to force sorting on the date column.

Thanks for the workaround. Sorry I didn't think to try that. (since nearly any app that has columns has a fair chance of also having sorting ability)

But I do see now that the "R" column doesn't show a sorting arrow icon by default. Perhaps that would be all that is needed for discoverability.

Along with that, if I choose to sort by a different column, there is no way to sort by the R column afterwards. So it's kind of a strange, "by default, but not available once changed" setting. (I can change sorting between other columns just fine) I can understand that someone reconciling a very long list might want or find the R column sorting useful, so I wouldn't say get rid of it entirely. Had the sorting arrow been present, I think I would not have even made the above comment, but I'd still vote to make Date the default sort column which would preserve behavior from previous versions as each transaction was checked.

I will look at this, I think I forgot to change the default column to sort. I will change the numbers to enum defined.

Do you want the R column to sort, it will make it wider ?

Bob, not sure if comment 15 was for me or Geert. I don't have a preference, but as noted in comment 14, I can see there might be a use case that someone would want to do so. Personally, I don't think a slightly wider column would be much of an issue. I'm not sure if there is a target minimum screen for GnuCash or if the window is flexible. I show the present window, for me, opens at 962px wide, so targeting a 1024 screen would give each R column 31px to play with. If the window adjusts down for screensize, then it's likely not an issue at all. (and if this gets later moved to a tab instead of a transient-for dialog it won't matter anyway)

There are apparently users with 800x600 screens and they whine piteously if GnuCash windows and dialogs won't fit in that space. For the reconcile window they may have to live with horizontal scrollbars in the treeviews, but allowing that should get the window smaller than 799px wide.

Created PR345 to fix this.

I also enabled the sort for the reconcile column as the two tree views already have scrolling and on my VM there was minimal scrolling when window was at 800px wide also with ability to specify the font size it should not be an issue.

*** Bug 796046 has been marked as a duplicate of this bug. ***

This problem has been fixed in our software repository. The fix will go into the next software release (3.2). Once that release is available, you may want to check for a software upgrade provided by your Linux distribution.

GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=795101. Please update any external references or bookmarks.