Le lundi 01 septembre 2008 Ã 10:49 +0200, Philip Van Hoof a Ãcrit :
On Mon, 2008-09-01 at 10:25 +0200, Lubos Lunak wrote:On Friday 29 of August 2008, Philip Van Hoof wrote:Is this API also intended to be used by filemanagers? It appears to have several performance problems for use in those: - there is no notification about progress (i.e. when a thumbnail is done), so a filemanager showing a directory would have to wait for all thumbnails created there (unless it wants to watch the thumbnail directories for a change). Also, even if there was such a signal, it would probably be nice to also have a request for cancelling the create request, in order to change what should be generated when the user scrolls around in a view with many filesI have not seen many other thumbnailers have progress or status information. You could do per-item progress information by calling it file per file. I could add a signal like: <signal name="Progress"> <arg type="s" name="level" /> <!-- Either "item" or "group" //--> <arg type="i" name="percentage" /> </signal> I'm not sure if this ain't making the specification too complex for implementers for a thumbnailer. 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.
actually this is imho not overkill at all, one minute is your limit but on what kind of hardware with what kind of file ? I've been reading through how nautilus does browsing and queues thumbnailing and this is done in a highly asynchronous way. If a user closes window then all actions pending for this window are _immediately_ stopped. This is what I expect from a reasonable process, don't waste time doing something I don't care anymore, just work on the stuff I'm doing now. -- Gilles Dartiguelongue <gilles dartiguelongue esiee org>
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=