[Redirecting to CnuCash Devel list]
--On August 7, 2013 10:29:15 PM +0200 Geert Janssens
<[email protected]> 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
_______________________________________________
gnucash-devel mailing list
[email protected]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
