Re: Consolidating Core Desktop libraries
- From: Ivan Frade <ivan frade gmail com>
- To: Zeeshan Ali <zeenix gmail com>
- Cc: Felix Riemann <friemann gnome org>, desktop-devel-list gnome org, Bastien Nocera <hadess hadess net>
- Subject: Re: Consolidating Core Desktop libraries
- Date: Mon, 22 Nov 2010 23:38:10 +0200
On Sun, Nov 14, 2010 at 4:21 PM, Zeeshan Ali <zeenix gmail com>
> > One could also think
> > about reanimating the once proposed d-bus-based thumbnailer if more
> > users show up.
Rygel also needs this. Currently we just serve the thumbails if they've been already created by another app but its very much desired to be able to create them ourselves or request another entity to do that.
True and one reason I'm not using it already in Rygel. Another reason to not use this spec is that IMHO we should have one service for both thumbnail and albumart extraction/download with simple APIs (get the thumbnail/albumart for this URI/album/artist and notify me when its done).
Maybe the spec is too verbose, but the API itself is simple for application developers: a "Queue" method to request the thumbnail, and a "Ready" signal with the URI of the result. This is really what needs to be wrapped in a nice GObject-based library (GThumbnail?)
Then, as optimization, there are also the methods to avoid the recreation of the thumbnails when the images are moved/copied. There is a third part in the spec, to extend the thumbnailer daemon with out-of-process plugins accessible via DBus.
These APIs are implemented by tumbler (open source, coming from the XFCE project) and it is used also in MeeGo.
Album art is a different issue, and you depend there on external providers. Not that is not possible, but requires a second thought. In any case a common thumbnail system in the platform is good. Probably it deserves its own thread to discuss if somebody else is interested.
] [Thread Prev