Comment 3 for bug 524567

Hi,

I am the author of https://code.launchpad.net/~mmcg069/software-center/fastappview-kinda-working. The important class is in softwarecenter/view/appview.py, the class name is AppView.

My approach is to maintain an internal 'complete list' (AppStore) and a 'visible list' (AppView.vis_list). The visible list only takes from the complete list what is required to satisfy visual needs, i.e. only lookup from the complete list and update the treeview for the AppStore rows that are visible (make sense?). Typically, when USC is maximised, my bona fide gtk.treeview only has to deal with ~20 rows of data at my resolution of 1152x864.

I have this working quite nicely for mouse scrolling and small increments, big drags (drags that move through the list in row-steps > vis_range) are still quite sluggish.

Latency is all but gone on treeview updates. Before a noticable amount of time was spent recalcing the treeview when a row was selected. This treeview churn interrupted pathbar animations, making them jerky. This is mostly gone in my branch even with large lists (200+ rows).

Moreover, my approach according to mvo is faster to load than a traditional treeview. As per a conversation with mvo in irc, in one case wrt USC, we went from 2 secs to 0.4sec to load the treeview. Although i am not sure if this still holds true and not sure what size list produced this result. Regardless this still sounds nice! :)

Obviously my efforts are far from perfect. There are things i dont really understand about the treeview that mean i can't quite get the alignment of rows perfect at the upper extent when using the keypad to iterate through the list.

Things i dont get that are hindering my approach include:

* I dont know how to ungrab a focal row. A double-click emits an activation that (to me) seems a special case. The row focus no longer becomes bound to the selection, i.e. i can unselect_all and yet there remains a focal row. And since my method basically recycles rows, a focus rect is retained for the iter/path activated and is visible when scrolling, despite no row being selected. Creates visual yuckness. Any suggestions on a api call to ungrab a row?

* I dont get how to calc the vadjustment.upper value wrt to the treeview. If the expanded row is visible, my upper val is correct. If the expanded row is not visible, then i display an extra row with junk data. I guess i should be nudging the treeview vadjustment.value in this case to make things look correct?

Hope this makes some sense, any advice greatly appreciated!