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!

-- 
Software list views with variable-height rows scroll slowly
https://bugs.launchpad.net/bugs/524567
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.

-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to