Re: GnomeDesktopThumbnail API replacement

[Bastien Nocera <hadess hadess net>]

Hey Philip,

On Mon, 2018-01-22 at 09:28 +0000, Philip Withnall wrote:
> On Wed, 2018-01-17 at 18:15 +0100, Bastien Nocera wrote:
> > On Wed, 2018-01-17 at 13:15 +0100, Bastien Nocera wrote:
> > > Hey,
> > >
> > > I wanted to start a discussion about replacing
> > > GnomeDesktopThumbnail
> > > with an API that would live in the GLib/GTK+ stack.
> >
> > <snip>
>
> From the GLib side of things, my thoughts are that this shouldn’t
> live
> in GLib, since it deals with pixbufs. As long as it integrates with
> GIO’s thumbnail attribute support, GLib will be happy.

OK. Now the question is whether gdk-pixbuf or GTK+ would be the best
place for it.

> What about https://wiki.gnome.org/DraftSpecs/ThumbnailerSpec? I don’t
> know if the API is entirely relevant (or whether explicitly exposing
> the cache over D-Bus makes sense), but there may be some useful ideas
> there even if the API as a whole is not a good fit.

It's an implementation, rather than an API. As an API, it fails to
bring anything more to the table, apart from conflict resolution when
two thumbnailers offer to thumbnail the same mime-type. Nothing that
interesting as to make the API any more complicated.

> What did you have to say about making things free-Unix-specific (or
> more Linux specific)?

Well, I just didn't know which other API I should base the
implementation on. Should this also work on Windows or macOS, or at
least be prepared to? What APIs do they use, and are they similar
enough that this proposed API would work for them?

<snip>
> Seems reasonable, though I assume people will typically use the
> *_async() version?

Right, it's easier to just show the sync version, and readers can infer
the (more versbose) async API.

>  The *_sync() version should still have a
> GCancellable argument.

Yes, I forgot that.

>  I agree with using a GFile rather than a raw
> URI.

OK.

>  If this is done as a shared library then you can implement it
> using bwrap or D-Bus as you see fit, and change the implementation
> later on without problems.

Indeed, I'll ask people in the know how they think this would play out.

Cheers