Re: patch nag: Multithreaded thumbnail loading

[Alexander Larsson <alexl redhat com>]

On Sat, 2007-09-08 at 14:20 +0200, Christian Neumair wrote:
> Am Montag, den 03.09.2007, 13:15 +0200 schrieb Alexander Larsson:
> > There is a limited amount of threads loading the thumbnails, therefore
> > it makes sense to load the ones that are actually visible first. We
> > might not actually use the precise code in
> > nautilus_thumbnail_prioritize(), but at least it would hooks into the
> > same places.
> 
> Thanks for your fruitful comments. I've implemented the relevant changes
> you requested.

Looks pretty good, I commited it (since today is freeze) as it looks
pretty safe to me. (But please watch out for breakage from this.)

> In my local tree, I added an async variant of
> nautilus_thumbnail_load_image(). We only seem to be able to set the
> priority when the thumbnail is requested, and lack a way to modify the
> priority of running asyncronous GnomeVFS request ("running" as of "has a
> handle", but still I/O to do).
>
> If we have such a job run-time priorization mechanism (GVFS?), we should
> be able to just change the thumbnailing priority in a function that can
> be called from the _prioritize() function. Are you OK with that?

I guess this sounds good. I'm not sure all backends supports changing
prio once i/o is started, but we can do as well as we can.

> It may be a good idea to add a status bar message priority system, to
> implement notifications regarding folder operations (loading etc.). One
> would would be able to push messages on a stack and pop it from it, and
> give them a priority, and we can have separate priorities for basic
> file/folder information (_LOW), file operations (_NORMAL) and tooltips
> (_HIGH), that decide which one is actually shown. It would be some form
> of gtk_statusbar_push and gtk_statusbar_pop wrapper that reorders the
> messages according to their priority.

Yeah, that might be useful. Is there a lot of conflicting status
messages though?