Announcement: GnuCash 2.5.4 (Unstable) Release 2013-08-05

[Geert Janssens]

On 06-08-13 17:20, David Carlson wrote:
> I really like the new register2 window behavior in the 2.5.4 release.
> It takes a little getting used to with the 'Coarse' slider on the left
> and 'fine' slider on the right, but once I figured it out, it works very
> nicely.
>
>   It seems to solve the register loading times nicely too.
>
> David C
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
I'm afraid I don't share your enthusiasm for this new feature. I agree 
it does improve the load speed.

But I don't like two vertical scroll bars as this introduces several 
usability problems. Just to name a few:
- two scrollbars is not typically used in other applications. So this 
creates an unusual interface which will certainly confuse many 
not-so-technical users.
- It defeats user interface consistency and with this reduces the 
ability of users to reuse their habits. For example: in most programs, 
the right scrollbar is a quick visual clue to where you currently are in 
the displayed data. The visual clue is now in the left scrollbar, but 
not immediatly obvious.
- The right scrollbar thumb's behaviour seems arbitrary. While moving 
through transactions it follows its own logic to move up and down. For 
example, while scrolling down using the arrow keys, the thumb will jump 
up and down while new row sets are loaded and old sets are discarded.
- Behaviour inconsistencies: using arrow keys, page up/page down, you 
can navigate the full transaction history. But using the mouse scroll 
wheel, you can only navigate the transactions in the loaded set.

I do appreciate the effort, but I don't think this is the direction the 
new register code should go. The second scrollbar got introduced as a 
side product to work around a performance issue. But IMO user interface 
elements should only be introduced to improve the human-computer 
interaction.

There must be another way to handle this. There are many applications 
that handle large sets of data, yet they don't need two scrollbars to 
achieve acceptable performance. Think of music players with large music 
collections, photo managers, database admin tools,...

A quick search on the web suggests that GtkTreeView should be able to 
handle datasets of thousands to millions of records with no problems. 
Here's one discussion from the gtk list in 2011:
http://gtk.10911.n7.nabble.com/GtkTreeView-very-slow-for-large-lists-td12049.html

Hopefully we can find a solution that is both elegant and snappy to use.

Geert