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

I think any guess you make about how many rows are displayed are going
to be naive, but there is no way around that I know of  without
modifications to the treeview control.  Unless the fixed-height-mode is
set, each row can be a different height, thwarting any attempt to
calculate their size by only examining the container.  However, I had no
better idea of how to do it so I saw guess high.

It is my understanding that you can obtain the physical size in pixels
of any control quite easily.   Currently I'm doing all fixed layout
stuff, which is super simple so I haven't tried with a control sized
with containment base layout.

I would pick two magic numbers rather than calculate the number of rows
based on size, since this would be much simpler and less likely to go
wrong.  Its not going to make much difference if you populate 10, 50 or
100 rows at a time, you just trying to keep the number down to something

The first magic number is how many rows you pull from your data source
when you need to, the other magic number is the threshold amount of rows
between the top of the grid and the last populated row.  For example,
you pull 200 rows initially and pull 200 more when the user gets within
100 rows of the end.

Of course, it would be much better if we knew exactly how many rows we
needed so we could say pull 200 rows initially then only pull 200 more
when the user exposes a blank row.  Might be possible to do this with a
custom cell renderer but I haven't looked into that yet.

On Thu, 2005-01-13 at 21:13, Fabricio Rocha wrote:
Hi, Greg,

          Just wondering about your problem (and testing if I can reply 
to the messages I see in the daily digest)...

          Is there a way to know the size in pixels a widget/container 
occupies in a given time? Maybe a Gdk function? If there is one, the 
maybe you could get the number of shown rows by dividing the treeview 
size by the average row size (probably something proportional to the 
font in use by GTK). You could have this calculation redone every time 
the resize event happened (size_allocate? size_request? check_resize?).

          I think that this solution is probably naive, but I am really 
a rookie in GTK andm if this idea does not work, I would also like to 
know how to "make things work"...


Fabricio Rocha

gtk-app-devel-list mailing list
gtk-app-devel-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]