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

Mike Alexander mta at umich.edu
Thu Aug 15 13:52:03 EDT 2013


[Redirecting to CnuCash Devel list]

--On August 7, 2013 10:29:15 PM +0200 Geert Janssens 
<janssens-geert at telenet.be> wrote:

> 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.

I agree with this.  If you can't make it load the whole register 
quickly enough (which seems odd since the old register certainly does) 
then it should be possible to use a single scroll bar to scroll through 
the whole register even with only part of it loaded.  I once 
implemented something much like this in a table editor for an XML 
document editing program where tables could contain thousands of rows. 
The scroll bars reflected the size of the entire table even though the 
display only loaded the visible rows and a few on either side, much 
like you're doing with the register code.  Getting the scroll bars 
right may be a bit tricky, but it should be possible.

              Mike
 


More information about the gnucash-devel mailing list