Re: Specifying thumbnailers as a service
On Fri, 2008-08-29 at 20:14 +0200, Kevin Krammer wrote: On Friday 29 August 2008, Philip Van Hoof wrote: What do others think about having a signal like this signal name=Created arg type=as name=thumbnails / /signal I know that Create is annotated as async but the client might want to start using/displaying thumbnails as the come in, e.g. in batches, and not wait until all requested ones have been completed. This change is done already, only it's called `Ready` http://live.gnome.org/ThumbnailerSpec -- 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 ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Specifying thumbnailers as a service
On Sat, 2008-08-30 at 01:12 +0200, David Faure wrote: On Friday 29 August 2008, Brian J. Tarricone wrote: [cut] This sounds overly complicated to me. Now you're assuming that any app that wants to load thumbnails is also capable of figuring out the mime-type of the file it wants to load. [cut] I agree, it's the job of that service to figure out the mimetype (and therefore the actual backend) to use. [cut] Hmm, maybe that's as simple as saying that: org.freedesktop.thumbnailer.generic is used by default, and that one can find out and call a org.freedesktop.thumbnailer.specific mime type service if it doesn't know how to handle that mimetype itself. I'll try to write the draft of the specification this way. At Maemo we will implement a daemon for our own use-case and if this kind of DBus stuff turns out to be impractical then we'll immediately notice this during the implementing of our case. -- 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 ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Specifying thumbnailers as a service
On Friday 29 of August 2008, Philip Van Hoof wrote: Hi there, Not only filemanagers want to request the creation of a thumbnail. For example desktop search engines like Strigi and Tracker want to schedule the creation of thumbnails for certain of the contents that they find, ahead of time (not sure about Strigi, as one of Tracker's developers myself I'm sure about Tracker). This is why we would like to have a desktop wide DBus API for requesting the creation of a thumbnail. Not just a specification about how to store the thumbnails and where you can find them [1], but also a method to request thumbnails. We want to reuse the infrastructure that is available. We want to request the creation of a thumbnail for rather a lot of items so this API would have to accept a an array of paths to thumbnail-able items. When finished it would return an array of paths to the thumbnails. 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 files - not in your original proposal, but in the thread it is said that the create request should not request a specific size, instead the thumbnailer should handle sizes normally according to the thumbnailing spec. This would make the generation take longer and presumably waste space with unused sizes. - thumbnail generators usually don't go via saving to disk but use some more efficient way (e.g. pass data in-process) - also, it is not really necessary to actually keep thumbnails on the disk, I use my image browser with the disk cache turned off, as that's generally faster that way. The API however cannot work this way. Since all applications using this API need to be handle the thumbnail spec anyway, wouldn't it be better to have the API like image create_thumbnail( string file, int size ) ? Plus some simple way how to find which .so to load for this entry hook? -- Lubos Lunak KDE developer -- SUSE LINUX, s.r.o. e-mail: [EMAIL PROTECTED] , [EMAIL PROTECTED] Lihovarska 1060/12 tel: +420 284 028 972 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Specifying thumbnailers as a service
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 files I 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. - not in your original proposal, but in the thread it is said that the create request should not request a specific size, instead the thumbnailer should handle sizes normally according to the thumbnailing spec. This would make the generation take longer and presumably waste space with unused sizes. Which thumbnail-sizes to generate is a configuration / implementation detail of the thumbnailer. On a tablet PC, for example, I guess that only the small size might be sufficient. We could do something like this of course: method name=Create annotation name=org.freedesktop.DBus.GLib.Async value=true/ arg type=as name=uris direction=in / arg type=s name=kind direction=in / !-- Either small, normal or both //-- /method I wonder what other people's opinion is about this? - thumbnail generators usually don't go via saving to disk but use some more efficient way (e.g. pass data in-process) Passing pixbuf data over IPC doesn't sound very efficient to me. I also wonder why you would do that over IPC?! Just make a library that does it for your application (like your `create_image` below). Your service is in your use-case not doing anything that you would expect from a service. So why make it a service then? However. For some files (and file-types) will the generation of a thumbnail take a lot of time, so when most applications request a thumbnail, they mean: create me the thumbnailcache for this file and callback when they request the creation of the thumbnail. For the purpose of specifying the storage of that cache, we already have http://jens.triq.net/thumbnail-spec/index.html This proposal is about specifying requesting the creation of a thumbnail in that cache. You can of course still make a library that just creates the thumbnail. But that's only related in so far that this library could consume that service (if the library is configured to do so). - also, it is not really necessary to actually keep thumbnails on the disk, I use my image browser with the disk cache turned off, as that's generally faster that way. The API however cannot work this way. Since all applications using this API need to be handle the thumbnail spec anyway, wouldn't it be better to have the API like image create_thumbnail( string file, int size ) This specification is not intended to be a replacement for a library that gives you thumbnails in a specific pixbuf format. It's intended to ask for a request for the creation of a thumbnail in a thumbnail-spec formatted cache (and to reply when finished). A possible consumer of that service would be the library that implements a function like create_thumbnail. ? Plus some simple way how to find which .so to load for this entry hook? That's not related to the specification being proposed, but related to a library for passing the thumbnail in the form of a pixbuf to the application developer. -- 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 ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Specifying thumbnailers as a service
On Monday 01 of September 2008, Philip Van Hoof wrote: 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 files I have not seen many other thumbnailers have progress or status information. You mean, besides those built-in in image viewers or file browsers. 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. It wasn't meant for a user. If the user scrolls the view, then the visible files should get thumbnails first. The simplest idea seemed to be cancelling and starting anew. (This was meant under the assumption that it would be for real-time generation of thumbnails, which appears to be false.) - thumbnail generators usually don't go via saving to disk but use some more efficient way (e.g. pass data in-process) Passing pixbuf data over IPC doesn't sound very efficient to me. I also wonder why you would do that over IPC?! Just make a library that does it for your application (like your `create_image` below). I'll take this as no to my original question about whether your proposal is also meant for apps like file managers (i.e. real-time generation). In that case, however, I suggest you use a better fitting name. A thumbnailer I would say is something that creates a thumbnail (that is, a picture) out of a file. What you are suggesting is thumbnail management. For some files (and file-types) will the generation of a thumbnail take a lot of time, so when most applications request a thumbnail, they mean: create me the thumbnailcache for this file and callback when they request the creation of the thumbnail. The problem already exists even now, doesn't it? And presumably has been already solved somehow. For the purpose of specifying the storage of that cache, we already have http://jens.triq.net/thumbnail-spec/index.html This proposal is about specifying requesting the creation of a thumbnail in that cache. You can of course still make a library that just creates the thumbnail. So, again, this is not about thumbnailers, this is about thumbnail management then. It was not clear to me from your original mail. -- Lubos Lunak KDE developer -- SUSE LINUX, s.r.o. e-mail: [EMAIL PROTECTED] , [EMAIL PROTECTED] Lihovarska 1060/12 tel: +420 284 028 972 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Specifying thumbnailers as a service
On Mon, 2008-09-01 at 13:59 +0200, Lubos Lunak 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. It wasn't meant for a user. If the user scrolls the view, then the visible files should get thumbnails first. The simplest idea seemed to be cancelling and starting anew. (This was meant under the assumption that it would be for real-time generation of thumbnails, which appears to be false.) If your thumbnailer is asynchronous it could also prioritize requests in a LIFO queue. I think the recommendation should indeed be to make the thumbnailer handler handle requests asynchronously and we could recommend LIFO for this. Would that solve the use-case you have in mind for canceling? I really think having a reliable cancel is a bit overkill, quite hard to both specify and implement too. For example, how soon must a cancel take place? Relatively few thumbnail algorithms have reliable cancel points embedded (if any). A function like pthread_cancel() shouldn't be used here, as that will inevitably lead to leaking and unportable code. So if we drag cancellations into the specification, we make it more or less impossible for an implementer to fulfill the entire specification correctly. Usually (always) impossible-to-implement specifications are bad ones. - thumbnail generators usually don't go via saving to disk but use some more efficient way (e.g. pass data in-process) Passing pixbuf data over IPC doesn't sound very efficient to me. I also wonder why you would do that over IPC?! Just make a library that does it for your application (like your `create_image` below). I'll take this as no to my original question about whether your proposal is also meant for apps like file managers (i.e. real-time generation). In that case, however, I suggest you use a better fitting name. A thumbnailer I would say is something that creates a thumbnail (that is, a picture) out of a file. What you are suggesting is thumbnail management. A better name is indeed thumbnail management. You can of course still make a library that just creates the thumbnail. So, again, this is not about thumbnailers, this is about thumbnail management then. It was not clear to me from your original mail. Ok We can of course mention this name in the request-bug (a specification for thumbnail management) (done). https://bugs.freedesktop.org/show_bug.cgi?id=17376 -- 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 ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Specifying thumbnailers as a service
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. 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. 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... -brian ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Specifying thumbnailers as a service
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 ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Specifying thumbnailers as a service
On Tue, 02 Sep 2008 00:09:53 +0200 Philip Van Hoof wrote: 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. Yes, but that still doesn't solve the problem since thumbnails don't take zero time to create. I can scroll down a list of 500 photos in a file manager slowly enough so thumbnail creation is triggered for all of them, but close the window before thumbnails for even a quarter of them are generated. He could just prioritize the visible ones, and in a timeout check, if the window is not closing, request thumbnails for nearby invisible items. Right, but you're assuming the user won't scroll around all that much. That's a very unsafe assumption. No need for cancels ... Still disagree. Just requesting all and canceling the unfinished ones when the window is closing, sounds like messy programming to me. Nowhere did I suggest the file manager implementer would do this. I'm pretty sure most filemanagers are already doing such optimizations for their thumbnailing work. Maybe even more clever ones. Yes, they're implementing all you've suggested above... including things like cancellation of in-flight (and queued) thumbnailing. 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). If the user is scrolling down the list slowly enough, potentially *all* items in the directory might become visible and queued. You can *never* assume the user isn't going to trigger the worst-case performance in your application. 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). What's the point of this if you're already starting a list of applications that won't want to use it? I'd say potentially the biggest consumer of thumbnails on the desktop would be the file manager. If that's true (maybe it isn't, this is just my feeling), shouldn't a spec covering thumbnails think about its largest user? 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? I'm not. But thumbnailers that don't offer great ways to cancel in mid-progress would need to be if they want to support cancellation in a reasonable manner (with a reasonably short delay). 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? Oh please. You're picking the most naive, crappy implementation idea as your rebuttal? So I take it you'd expect that the analogous in-process thumbnailer would create 15,000 simultaneous threads to create its thumbnails? Any competent implementer of the main daemon service that intends to support out-of-process thumbnailers would queue requests and only have a small number of them in flight at any time. Just like any competent implementer who only wants to support in-process thumbnailers would queue them and not run them all at the same time (in threads or otherwise). And also note that, with this kind of queuing architecture, cancellation for 'jobs' that are still in the queue and haven't started yet is trivial to implement. Even if you don't want to support fine-grained cancellation or out-of-process thumbnailers, if you have 15,000 requests queued and the thumbnailer is currently
Re: Specifying thumbnailers as a service
On Fri, 2008-08-29 at 11:25 +0200, Philip Van Hoof wrote: arg type=i name=size_x direction=in / arg type=i name=size_y direction=in / In the libgnomeui API, you only set one of those, and aspect ratio is preserved. The size passed is the maximum width and height. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Specifying thumbnailers as a service
Bastien Nocera a écrit : On Fri, 2008-08-29 at 11:25 +0200, Philip Van Hoof wrote: arg type=i name=size_x direction=in / arg type=i name=size_y direction=in / In the libgnomeui API, you only set one of those, and aspect ratio is preserved. The size passed is the maximum width and height. Well, we can have the Qt approach here : keep width and height, and add a third parameter which is PreserveRatio (actually in Qt there are three possibilities : keep ratio, don't keep ratio and extend, see http://doc.trolltech.com/4.4/qpixmap.html#scaled ). Cheers Adrien ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Specifying thumbnailers as a service
On Fri, 2008-08-29 at 12:14 +0200, Adrien BUSTANY wrote: Bastien Nocera a écrit : On Fri, 2008-08-29 at 11:25 +0200, Philip Van Hoof wrote: arg type=i name=size_x direction=in / arg type=i name=size_y direction=in / In the libgnomeui API, you only set one of those, and aspect ratio is preserved. The size passed is the maximum width and height. Well, we can have the Qt approach here : keep width and height, and add a third parameter which is PreserveRatio (actually in Qt there are three possibilities : keep ratio, don't keep ratio and extend, see http://doc.trolltech.com/4.4/qpixmap.html#scaled ). Why would you want to do that? ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Specifying thumbnailers as a service
Philip Van Hoof wrote: Hi there, Not only filemanagers want to request the creation of a thumbnail. For example desktop search engines like Strigi and Tracker want to schedule the creation of thumbnails for certain of the contents that they find, ahead of time (not sure about Strigi, as one of Tracker's developers myself I'm sure about Tracker). This is why we would like to have a desktop wide DBus API for requesting the creation of a thumbnail. Not just a specification about how to store the thumbnails and where you can find them [1], but also a method to request thumbnails. We want to reuse the infrastructure that is available. We want to request the creation of a thumbnail for rather a lot of items so this API would have to accept a an array of paths to thumbnail-able items. When finished it would return an array of paths to the thumbnails. For example (this is glib-dbus XML api) node name=/ interface name=org.freedesktop.Thumbnailer method name=Create annotation name=org.freedesktop.DBus.GLib.Async value=true/ arg type=as name=uris direction=in / arg type=i name=size_x direction=in / arg type=i name=size_y direction=in / arg type=as name=thumbnails direction=out / /method method name=Move annotation name=org.freedesktop.DBus.GLib.Async value=true/ arg type=as name=from_uris direction=in / arg type=as name=to_uris direction=in / /method method name=Delete annotation name=org.freedesktop.DBus.GLib.Async value=true/ arg type=as name=uris direction=in / /method /interface /node Nobody does something for no reason. Our own reason for wanting this is to have a platform wide thumbnailer for the Maemo platform and we want it aligned with upstream projects. A thumbnail service on a mobile platform is not going to have the same requirements as a thumbnail service on a KDE or a GNOME platform. It's my opinion that although the requirements are going to be different, the API for requesting the creation of a thumbnail isn't. Therefore, and this is a strong opinion of me: We make it more easy for our application developers if we cooperate on a DBus standard at the level of freedesktop.org, instead of each having our own client APIs for this. We can help with the work on patches for Nautilus and Konqueror. ps. Filemanagers could either become the providers of these DBus APIs, this is probably the most easy change, or if the architecture is chosen to offshore this functionality to a daemon they could be adapted to consume the DBus API instead. My proposal is *not* about having one great thumbnailer. If different teams want to compete on a thumbnailer implementation, then they must compete and that way drive innovation. This proposal is about the DBus API only for it (to see if we can reach an agreement on that). Hi Philip I wonder if it'd make sense to allow multiple services to provide thumbnailing for different mime types. This could be done by having the thumbnailing service(s) register bus names of the form org.freedesktop.thumbnailer.mime type, and the application could look up the bus name for the mime type of the file it wishes to thumbnail, and dbus-activation would take care of running the appropriate service. This would then allow proprietary providers of thumbnailing services for proprietary file types, or applications to provide thumbnailing of their own file types. However, I don't know if in general an application knows a file's mime type before it asks for the file. Of course, a plugin api for the thumbnailing daemon would also have much the same properties and may be simpler, though loosing the process protection. Just an idea ;) In terms of the above proposed API, I'm guessing that the 'thumbnails' out paramater on Create is returning a list of uris, which are 'freed' from use by the application by the Delete function? Also what is the Move method for? Thanks, Rob Thanks --- footnotes [1] http://jens.triq.net/thumbnail-spec/index.html -- Rob Taylor, Codethink Ltd. - http://codethink.co.uk ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Specifying thumbnailers as a service
Bastien Nocera a écrit : On Fri, 2008-08-29 at 12:14 +0200, Adrien BUSTANY wrote: Bastien Nocera a écrit : On Fri, 2008-08-29 at 11:25 +0200, Philip Van Hoof wrote: arg type=i name=size_x direction=in / arg type=i name=size_y direction=in / In the libgnomeui API, you only set one of those, and aspect ratio is preserved. The size passed is the maximum width and height. Well, we can have the Qt approach here : keep width and height, and add a third parameter which is PreserveRatio (actually in Qt there are three possibilities : keep ratio, don't keep ratio and extend, see http://doc.trolltech.com/4.4/qpixmap.html#scaled ). Why would you want to do that Well I don't know why I specially would like to do that, but it gives us flexibility without making the API more difficult to use (the ratio mode can be optional). Some people might want to have more control... This was just a good compromise between Philip's original idea, and the GNOME version. I don't have some real usecase behind that :-) ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Specifying thumbnailers as a service
On Fri, 2008-08-29 at 11:22 +0100, Rob Taylor wrote: I wonder if it'd make sense to allow multiple services to provide thumbnailing for different mime types. This could be done by having the thumbnailing service(s) register bus names of the form org.freedesktop.thumbnailer.mime type, and the application could look up the bus name for the mime type of the file it wishes to thumbnail, and dbus-activation would take care of running the appropriate service. This makes sense to me. This would then allow proprietary providers of thumbnailing services for proprietary file types, or applications to provide thumbnailing of their own file types. However, I don't know if in general an application knows a file's mime type before it asks for the file. Of course, a plugin api for the thumbnailing daemon would also have much the same properties and may be simpler, though loosing the process protection. Just an idea ;) Ok In terms of the above proposed API, I'm guessing that the 'thumbnails' out paramater on Create is returning a list of uris, which are 'freed' from use by the application by the Delete function? Also what is the Move method for? To let the thumbnailer know that a thumbnail-able have been moved, so that the thumbnailer can rename the thumbnail in a more efficient way than that a delete + create would do. -- 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 ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Specifying thumbnailers as a service
On Fri, 2008-08-29 at 11:03 +0100, Bastien Nocera wrote: On Fri, 2008-08-29 at 11:25 +0200, Philip Van Hoof wrote: arg type=i name=size_x direction=in / arg type=i name=size_y direction=in / In the libgnomeui API, you only set one of those, and aspect ratio is preserved. The size passed is the maximum width and height. Or we make it even more simply and have normal, big, small only. The client receives paths, not pixbufs. So the client is going to be responsible for resizing anyway. Else the thumbnailer would have to make subdirectories in .thumbnails for all sizes ever requested. Instead of giving a near match and letting the consumer of the thumbnail do a resize. I don't know, what is the experience of other thumbnailers on this issue? I'm not sure if we by definition have to support exact pixel sizes. Just normal, big, small (and maybe allow huge and tiny too). Less is more ;-) - not sure if it's applicable here - -- 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 ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Specifying thumbnailers as a service
On Fri, 2008-08-29 at 13:59 +0200, Philip Van Hoof wrote:
On Fri, 2008-08-29 at 11:03 +0100, Bastien Nocera wrote:
On Fri, 2008-08-29 at 11:25 +0200, Philip Van Hoof wrote:
arg type=i name=size_x direction=in /
arg type=i name=size_y direction=in /
In the libgnomeui API, you only set one of those, and aspect ratio is
preserved. The size passed is the maximum width and height.
Or we make it even more simply and have normal, big, small only.
Or we make it even more simple, and we don't deal with sizes at all.
The thumbnailer must make all sizes it supports. It's actually an
implementation detail of the thumbnailer vs. the library for accessing
them.
This DBus specification is only about requesting the creation of a
thumbnail. It's the responsibility of a library to do the final
resizing operation and pass it as a toolkit specific pixbuf instance to
the application developer (in gtk+ that's for example GdkPixBuf).
We don't pass pixbufs over DBus, that makes no sense.
Which also means that we don't return any uri. That client library
calculate that path by following the thumbnail-spec [1].
Therefore isn't the uri of the thumbnail itself relevant for DBus.
That, combined with Rob Taylor's proposal, brings me to this DBus API:
node name=/
foreach ([mime-part] in supported_mime_parts) {
interface name=org.freedesktop.Thumbnailer.[mime-part]
method name=Create
annotation name=org.freedesktop.DBus.GLib.Async value=true/
arg type=as name=uris direction=in /
/method
method name=Move
annotation name=org.freedesktop.DBus.GLib.Async value=true/
arg type=as name=from_uris direction=in /
arg type=as name=to_uris direction=in /
/method
method name=Delete
annotation name=org.freedesktop.DBus.GLib.Async value=true/
arg type=as name=uris direction=in /
/method
/interface
}
/node
--- footnotes
[1] http://jens.triq.net/thumbnail-spec/index.html
--
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
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Specifying thumbnailers as a service
On Fri, 2008-08-29 at 14:34 +0200, Philip Van Hoof wrote: interface name=org.freedesktop.Thumbnailer.[mime-part] It seems odd to include the mime type in the _interface_ name; shouldn't this be generic instead? (Also keep in mind that both object paths and interface names in D-Bus are really limited in terms of what characters are valid.) David ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Specifying thumbnailers as a service
On Friday 29 August 2008, Philip Van Hoof wrote:
[snip]
That, combined with Rob Taylor's proposal, brings me to this DBus API:
node name=/
foreach ([mime-part] in supported_mime_parts) {
interface name=org.freedesktop.Thumbnailer.[mime-part]
I am not sure you need a separate interface name for each MIME type. Most
likely the thumbnail service will have to decide about the MIME type itself
anyway.
method name=Create
annotation name=org.freedesktop.DBus.GLib.Async value=true/
arg type=as name=uris direction=in /
/method
method name=Move
annotation name=org.freedesktop.DBus.GLib.Async value=true/
arg type=as name=from_uris direction=in /
arg type=as name=to_uris direction=in /
/method
method name=Delete
annotation name=org.freedesktop.DBus.GLib.Async value=true/
arg type=as name=uris direction=in /
/method
/interface
What do others think about having a signal like this
signal name=Created
arg type=as name=thumbnails /
/signal
I know that Create is annotated as async but the client might want to start
using/displaying thumbnails as the come in, e.g. in batches, and not wait
until all requested ones have been completed.
Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
signature.asc
Description: This is a digitally signed message part.
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg
