Re: GnomeDesktopThumbnail API replacement



On Mon, 2018-01-29 at 15:42 +0000, Debarshi Ray wrote:
On Mon, Jan 22, 2018 at 12:46:51PM +0000, Emmanuele Bassi wrote:
On 22 January 2018 at 09:28, Philip Withnall <philip tecnocode co.u
k> wrote:
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.

We could add a GThumbnail interface, like we did for GIcon,
GThemeIcon, and friends.

In the past, I had discussed making the thumbnailing APIs in GLib
more
complete with Allison. See:
  https://bugzilla.gnome.org/show_bug.cgi?id=686895#c20

I extracted 3 comments which could be relevant to the discussion:

However, the edits are application-specific [2], so it is not
reasonable to expect the generic OS-wide thumbnailers to be able to
handle them.

This is solved/worked-around when using Flatpak, as the cache is
private to the app.

Secondly, it is important to be able to create and lookup thumbnails
of a specific size, as opposed to enumerated constants with pre-
determined presets.

This is a problem with the thumbnail spec's storage section. Jon added
a larger version quite some time ago, and somebody would need to go
through the process to make it any bigger.

Last but not the least, I find it important to version the cache to
tide over bugs in the thumbnailer.

You don't need the whole cache to be versioned. Thumbnailers can add
metadata to the thumbnails if they want, and doing:
gdk_pixbuf_save(pixbuf, "/path/to/thumbnail", "png", &error,
                "tEXt::Thumb::Software::Version", "1.0", NULL);
is do-able from within the thumbnailer, and that extra metadata would
be kept.

So there's definitely not much a thumbnailing API could do that you'd
need. The thumbnailing API takes files, and wouldn't make taking 2
sources (file + serialised image operations) possible. You want a
private cache because the on-disk file itself doesn't change. You want
bigger thumbnails, and the spec we implement doesn't allow that.

Thanks for the write-up. Let me know whether I missed anything.

Cheers


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]