Re: GtkTreeView with huge amount of rows; dynamic data source?

[Gus Koppel <gtk spamkiller bytechase cx>]

Greg Breland wrote:

> > I'm considering putting a custom, independent scrollbar next to the
> > GtkTreeView and use that one to navigate the list. However, at least
> > I'd need to know the number of visible rows in the GtkTreeView for
> > that. The window containing the GtkTreeView has to be resizable by
> > the user, of course, so assuming any fixed sizes / numbers of rows
> > isn't feasible.
>
> It would be much nicer if you could use a standard scrollwindow, have
> the liststore "Fake" out 100K rows and then on the scroll event check
> to make sure the liststore is populated with data.
> [<...>]
> I don't think there is a simple way to determine how many rows a
> liststore is displaying,

Not sure, see below.

> but this can be solved by populating more rows than you need.

Unfortunately not.

> So figure that the typical row is 20 pixels high, on a 2000x2000
> screen that would be 100 rows.  So take the top row position and make
> sure that the list store is populated for 200 rows below that. Not an
> ideal solution, but a reasonable workaround.  Even better would be to
> base your calculation on the actual size of the TreeView control to be
> more efficient.

Your pixel numbers differ greatly from mine, btw. Imagine, the
GtkTreeView can display anything between 5 and 50 rows, depending on its
current size. If the application gets no idea about its current size the
scrollbar appearance and behaviour would go havoc. Most obviously the
slider proportions would completely fail. Imagine, the result set
contains just 100 records at all. If the treeview can display 50 rows,
the slider should occupy 50% of its area. If 5 rows are displayed, the
slider should occupy just 5% of the area. If I manage my own scrollbar
and have no idea about how many rows are currently being displayed,
there's no way in adjusting the scrollbar's appearance appropriately.

But even if I were to fall back to old, ugly Windows 3.x scrollbar
appearance, which is merely a fixed-size knob instead of a proportional
bar, I would still have a problem. Imagine, the result set contains only
40 rows. If the treeview displays only 5 rows, there must certainly be a
scrollbar/knob. If the treeview is large enough to display 50 rows,
however, there certainly mustn't be, except if you are willing to
seriously confuse users with non-standard and non-intuitive GUI
behaviour. So the application desperately needs to know the number of
rows being displayed in a GtkTreeView to perform proper custom scrollbar
management.

Neither restricting the GtkTreeView to a fixed size nor making
unevaluated assumptions about the pixel height of rows are an option.

Possible solution:

My plan is still to manage the scrollbar of a GtkTreeView on my own.
Apparently intercepting existing or providing an own GtkAdjustment for
the GtkScrolledWindow, along with repeatedly rebuilding underlying
GtkListStores or GtkTreeStores is the way. I still have to find out how
to do it exactly, but I think my solution will work like this:

1. using a GtkTreeView within a GtkScrolledWindow, just as usual.

2. calculating from GtkAdjustment's <page_size> how many rows of the
   data source are to be read / can be displayed in the GtkTreeView.

3. reading exactly the number of visible rows from my data source,
   starting at the appropriate start position, and filling a
   GtkListStore or GtkTreeStore with it.

4. foist the total number of rows in my data(base) source (instead of
   rows in the GtkListStore / GtkTreeStore) on the GtkAdjustment's
   <upper value>, and the current result set offset on the
   GtkAdjustment's <value>.

5. if the user scrolls / moves the scrollbar, go to step 3.

6. if the user resizes the GtkTreeView, go to step 2.

I still have to figure out how to intercept the GtkAdjustment values
which are obviously being exchanged between the GtkTreeView and the
GtkScrolledWindow. As the GTK+ documentation doesn't seem to be a great
help in explaining how to implement something like this, I'd have to
study quite some GTK+ sources, I think, which I'd like to avoid at this
time. Comments and advices on this strategy are appreciated.