I'm writing something for Totem, and I want a GtkTreeView to have more rows added to it as you scroll down.
So far I've got it adding more rows nicely when you get to about 80% of the way down the GtkAdjustment, by listening to the adjustment's "changed" signal, but then it keeps on adding rows (ideally it should only add 20 at a time then stop), and the handle of the scrollbar screws up. I presume this is something to do with the fact that the handle is grabbed at the time, and so probably can't resize, or something.
Anyway, has anybody implemented anything similar before (or seen such a feature somewhere) so that I can see where I'm going wrong? I could've sworn I'd seen something similar before (I'm not original enough to think up such features myself 
), but I can't find it. Answers on a postcard, please. 
The scrollbars in Gnumeric do something similar to this. you can scroll into infinity, but usually only the used area is shown in the slider sizes.
There is a similair thing in open office calc. I dont know how its working behind the scenes, but it might be worth looking into.
I don't think I've ever seen/used a Gnome application which does this, but for example Google Reader does. Maybe you've seen the feature in a web application as well? I guess this wasn't helpful at all...
Perhaps http://www.pvanhoof.be/wiki/index.php/Smart_ways_of_using_GtkTreeView would be helpful. Not sure what you're trying to do though.
Maybe you could immediately set the size of the adjustment to reflect the total number of rows you plan to put in your TreeView (if you know it). That way, you would avoid the problem of always being at 80% of the way down since you would just have to load the current "frame" of rows. I never tried that though, so I don't know if that's possible.
XUL currently has support for doing this using their tree widgets. Unfortunately since widget drawing is done from a theming api, its probably not useful here.
What i have done in the past is write my own treemodels and lazy load the data as it is required. The key to making this fast is using the integer row offset as the user_data in the GtkTreeIter. You can also speed the results here with a LRU cache or similar.
I have a couple different implementations of this using sqlite for storage in C and python.
http://vwdude.com/dropbox/pystore/
http://vwdude.com/dropbox/egg-sqlite-store/
I have a better version of the python implementation around somewhere if this isnt enough to get you going.
Euh, yes. Implement a custom treemodel and you'll know exactly when a row is to become visible and when it's to become invisible. You can (must) then provide the data for that row (for each column) and at that time you can load your data.
In other words: follow the Model View Controller pattern.
The one thing that still sucks about doing your own treemodel and using integer row offsets for the GtkTreeIter->user_data is that GtkTreeView finds it necessary to iterate through every row on initialization. You can see how this would get annoying with say a million records.
This is especially a problem if your user_data is larger than sizeof(void*) because that means you cannot store an integer in the pointer space. I'm thinking 64bit primary keys in this example.
As I get older, I'm wondering if XUL isn't the right way to go for my new development. God I wish it was mainstream to embed python in XUL so you could do xpcom + script embed python.
Oh, and can the captcha's suck any harder in this place???
GtkTreeView does not have this behaviour if you set it to have fixed-row-height. The reason why it does this, is to calculate the scrollbar. You can ask Kristian Rietfield about the details for this. With fixed-row-height only the visible rows (and a few more rows, but not much) are kept in 'referenced state'. You have a method called ref and one called unref to implement in the custom tree model, those are the ones you need.
Try it with a printf first, you'll notice the behaviour and whether the fixed-row-height property of the view improves it.
You can also take a look at the wiki page, which I wrote, that somebody mentioned here. In a way, it does the exact same thing: you provide a hook for just before the rendering of the cell. It's, however, not possible to know when the cell becomes invisible (or not easy).
You mean something that Google Reader uses I believe. Maybe add a timer that waits until you let go of the handle and then update the treeview?
I use Ubuntu 7.10 & synaptic.
The Gdata Libary 1.0-1 is in the universe repository.
Do i have to compile SVN Totem or is there a .deb?
You could compile Totem from SVN, but I'd probably try getting a .deb from Hardy first, as I'm not sure that Gutsy's GData package is fully-functional (for example, it doesn't work properly with Python 2.5), and last time I tested, this meant that the YouTube plugin didn't work on Gutsy. A .deb from Hardy should be patched to deal with this, if appropriate.
See here for the Hardy packages: http://packages.ubuntu.com/hardy/gnome/totem