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
