As I have been experimenting with the LiveGridView, I've found that the limit on the view is roughly ~400K items (looks like some scroll calculation divided by row height, reducing the row height ups the limit). I don't really have an issue with the limit, I understand that beyond a certain point the scrolling math just won't make sense/work.
What would be nice would be to have a LiveGridView which would display 100K items, then combine that with the PagingToolBar to show multiple "pages" of 100K grids. However, I find that if I try to bind the PagingToolBar to the grid loader (the loader as created in the LiveGrid example), that the PagingToolBar doesn't seem to quite understand the intent (Paging on a LiveGridView).
That said, does anyone have a suggestion on how I might continue investigating how I might display such a large number of items in a grid? I like the idea of combining the above two examples together, but I have not been able to successfully do so thus far.
From a usability perspective, what are you trying to do? Both the live grid and the paging toolbar attempt to solve the same problem from two different angles - and both use the same tools to do so. Both draw in a Grid (though with different views), and both use a paging loader to specify a new offset and limit with each load. One uses a scrollbar and two ListStores to track exactly what data is where, and dumps data after it seems to be too far away, while the other just modifies the current set of items in the ListStore, thus updating the Grid. One is designed for people who want to scroll randomly (in the RAM sense) through the collection, while the other is more for people who know more or less where they expect to find things, usually the first or last page.
To build an interface that can couple these two together, you'll need to do something like start with a livegrid, then make a custom Proxy for it that compares the offset from the loadconfig (eminating from the livegird) with the offset in the paging toolbar. It may not even be possible to use the PagingToolbar class, but instead a Toolbar that has paging icons in it that modify the values that the proxy will make use of.
That said, back to my initial question: what are you trying to do? What kind of experience are you trying to create? If you are trying to make it easy to sift through the data to find specific details, a set of filters might make this task easier, either with the LiveGridView or the paging toolbar, depending on how those results will be dealt with.
Another question - do you still hit that scrollbar-too-small issue if you make the grid substantially taller? Or is it already as tall as it can reasonably be? It seems as though it should be possible to 'cheat' the numbers, and have the scrollbar could 1px as 10px, or whatever ratio is required to load the additional items - this isn't something built in, but could be a possible alternative. The downside would be that it wouldnt be possible to get to every item by dragging the scrollbar -- but honestly, who could use the scrollbar to find 1 out of 400k items...
From a usability perspective, I'll use a bad analogy. Imagine looking for needles in haystacks, and haystacks will be regularly added. A fairly thorough filtering mechanism already exists, however the number of results can range from 0 to far beyond what I found I could show using the LiveGridView (~400K).
The feature in question actually exists in a couple of alternate forms and I'm investigating a GXT 3.X implementation. One form does paging (like is done by the PagingToolbar), but it is a pretty poor user experience. The other is similar to the LiveGridView, but with a significantly higher upper limit. ~100K or so may be a reasonable upper limit, so LiveGridView would work for that, but if I get push-back I wanted to see if there was an existing solution to try and match an existing implementation (sounds like I may have to do something custom).
As per the scrollbar, it does not seem to affect the number of elements or at least it did not in my simple testing.