[haiku-development] Re: Image icons for images in Tracker

  • From: Stephan Aßmus <superstippi@xxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Fri, 02 Mar 2012 21:32:59 +0100

Am 02.03.2012 11:01, schrieb Axel Dörfler:
On 03/02/2012 10:45 AM, Stephan Aßmus wrote:
However. All that said, I would strongly urge you not to change
*anything* in Tracker (well, except see below). Instead, change
BIconUtils in the Interface Kit. Make it return icons based on the image
of the file. And please also special case using the JPEG translator,
such that it returns the thumbnail from the EXIF data, which it is
capable of. You have to read the translator's code to see how.

You mean to do this on the fly each time? That would be way too slow, if
that's your intention. Instead, BIconUtils should support reading bitmap
images from BEOS:ICON as well.

Yes, true. Caching is needed.

Since BIconUtils will necessarily work synchronously, putting the logic
to create the previews there won't really work that well. Instead, I
would still let Tracker create them when needed -- and also update them
when needed, ie. it should also store the last modified time of the file
into the icon attribute to see whether it's outdated or not.

BIconUtils OTOH could trigger the update of the icon (like updating the
MIME type of some file) asynchronously whenever needed, though. The icon
creator could then either still be Tracker, or could also be offloaded
to another process.

The question is indeed whether BIconUtils should be the one extracting the image and writing the cache, or not. Somehow I find it cleaner if it's BIconUtils doing it. That way you get a correct icon from it, without having to rely on another service or obtaining the icon again, once some other service got around to updating it. Makes the process harder to implement and not as flexible. For example, maybe you want to cause the icon updates in your own asynchronous thread. One reason to do so could be to cancel fetching an icon, maybe because the user already scrolled the file out of view.

I wonder if it would already work, if BIconUtils would extract and cache (store as icon) itself. IIRC, Tracker loads icons asynchronously already, no? At least I remember observing a Tracker window with tons of custom folder icons (album art) to seemingly load the icons asynchronously. For example, this window could be located at another workspace, and when I would switch to the workspace for the first time, only those icons were loaded that were in the visible part of the window. Scrolling up/down was possible without blocking, and the previously invisible icons would be fetched from disk, but with the pose names already displaying. Maybe I remember that wrongly, don't know. Or maybe it wouldn't scale to longer delays when fetching icons. But if it actually already works asynchronously, than changing BIconUtils may be all that's needed.

Best regards,
-Stephan


Other related posts: