On Fri, Jan 31, 2014 at 3:45 PM, Debarshi Ray wrote:
> Yes, I have noticed this too in gnome-{documents,photos}. See:
> https://bugzilla.gnome.org/show_bug.cgi?id=721402
>
> The way we work around this is by avoiding having to show 500 rows at
> once. We batch things in groups of 50 and as the user scrolls down we
> let her load another batch. That and letting the user search the data
> so that she does not have to browse through 500 or more items to find
> what she wants.
I'll think about this. I'd like to be able to scroll through the
directory without stopping, so handling load-ahead and unload-behind
without the user noticing (too much) sounds complicated. And the
scrollbar size/position might be misleading compared to the real
directory size. Thanks for the suggestion though.
> It might also be worth looking at what nautilus does.
Nautilus seems to use a custom widget called NautilusCanvasView. I've
tried to figure it out, but it's a lot of C code that I can't quite
grok. (And adding hundreds or thousands of lines of widget code to my
tiny program is daunting.) But yeah, Nautilus is good at being
responsive while thumbnailing a lot of files in a directory.
>> Also, it seems to happen when changing window focus.
>> GtkTreeView, however, is fast.
>
> Sounds like: https://bugzilla.gnome.org/show_bug.cgi?id=692348
Yeah, that bug seems to be it. Thanks for your reply.
_______________________________________________
gtk-list mailing list
gtk-list@xxxxxxxxx
https://mail.gnome.org/mailman/listinfo/gtk-list
