On Mon, 2008-09-01 at 09:53 -0700, Brian J. Tarricone wrote: > On Mon, 01 Sep 2008 10:49:31 +0200 Philip Van Hoof wrote:
> > I think canceling is overkill. Making a thumbnail doesn't take longer > > than a minute (and a minute is an extreme case). Users don't cancel > > that. > > Strongly disagree. I have a laptop, and say I'm on battery power. If > I'm scrolling through a big list of images in my file manager, and it's > requesting thumbnails, they all get queued. Then you must tell the developer of your filemanager that he should only request thumbnails for visible items, and for items that are likely going to become visible soon. Instead of immediately all items in the opened directory. He could just prioritize the visible ones, and in a timeout check, if the window is not closing, request thumbnails for nearby invisible items. No need for cancels ... Just requesting all and canceling the unfinished ones when the window is closing, sounds like messy programming to me. I'm pretty sure most filemanagers are already doing such optimizations for their thumbnailing work. Maybe even more clever ones. > Say I find the file I want near the end of the list (by file name, not > thumbnail) and close the file manager window... but the thumbnail service > keeps chugging along, uselessly creating thumbnails for 10s or 100s of > files, pegging the CPU and wasting my battery life. I wouldn't be > particularly happy about that. But then again, that wouldn't happen if the developer of the filemanger is clever and only requests thumbnails for items that are visible and perhaps after that starts with requesting the nearby items (and if the window is closing, stops sending more requests). Also note that this specification doesn't require a filemanager to use it. A filemanager can still do its own "specialized" thumbnailing, and it can even put thumbnail cache in $HOME/.thumbnail (the availability of a daemon doesn't mean that nobody else can write in that cache). > Cancellation could be easily implemented by returning an ID from the > Create request that can be used to cancel the operation. On the daemon > side, canceling the request could be as easy as killing a subprocess, > depending on implementation... Who says that the daemon will implement creating a thumbnail in a proces that can be killed? To be honest wouldn't that be a very good architec- ture for a thumbnailer service: Imagine the thumbnailer creating 15,000 processes in case the filemanager's developer didn't do it right and therefore did request thumbnails for all of the 15,000 items in your "Photos"-folder? I fear for your laptop's battery more than I feared when a few extra thumbnails didn't get canceled, if 15,000 processes got launched. I wonder if the kernel on a modest ARM device will actually schedule that sufficiently preemptive for the UI of the mobile to be responsive enough for the user not to simply shut it down thinking the device simply crashed completely. I don't think anything would redraw for at least a few minutes. -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be -- nautilus-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/nautilus-list
