GnomeDesktopThumbnail API replacement
- Date: Wed, 17 Jan 2018 13:15:18 +0100
- From: Bastien Nocera <hadess@xxxxxxxxxx>
- Subject: GnomeDesktopThumbnail API replacement
I wanted to start a discussion about replacing GnomeDesktopThumbnail
with an API that would live in the GLib/GTK+ stack.
We want to replace/move the current API because it lives in gnome-
desktop, which is a collection of helpers used by the core desktop, and
highly dependent on the environment in which it runs, which makes it
highly unsuitable for sandboxed applications, and given that has no API
guarantees, makes it unsuitable for applications to use.
It's currently not packaged inside the Freedesktop or GNOME runtimes
for Flatpak, and applications that need the thumbnailing API usually
build gnome-desktop with udev/hwdb support disabled.
This is the current API:
It requires GIO, which is fine, but also GdkPixbuf for its API. This
means that it would likely be a better for GTK+, but I also know that
we're trying to ween ourselves off of GdkPixbuf in GTK+.
I would also like the API to be free Unices specific, with an obvious
slant towards running on Linux (I'll get into that a bit later).
The obvious shortcomings of the API are:
- No builtin async support, so applications usually run the
thumbnailers inside threads, each using their own code for that,
meaning that some apps end up having GnomeDesktopThumbnailer I/O inside
the main thread because what API is blocking isn't clear. This should
also allow cancellation
- The function names are unclear, meaning that we end up with calls
like gnome_desktop_thumbnail_factory_give_me_a_thumbnail() in patches.
Maybe a single I/O bound entry point with flags is do-able.
Finally, we have the internal implementation to look into. I plan on
reusing the same ".thumbnailer" files to declare thumbnailers, as those
are used in a number of GNOME forks. The question here is more whether
we want to change the current internal implementation.
When asked to thumbnail a file, we look at whether the file is already
thumbnailed, and load it up if so, then check whether the filesystem
itself provides a preview icon, via GIO, and if not, look for a
thumbnailer which supports that file type.
Once we have the thumbnailer to use, we launch it either directly, or
inside bwrap on Linux systems to avoid both security and privacy
problems occurring through specially-crafted files.
But this is pretty slow (is this a real problem?), so I'm wondering
whether we could instead use a sandboxed/locked down longer-running
helper through D-Bus/systemd (turning off the network, disable reads or
writes in specific locations, etc.). This would run multiple
thumbnailers in parallel or in a series, which could have security
impact, though a much lower one than without any sandboxing, obviously.
To sum up, here are the questions:
- Do we want the API in GTK+ and depending on gdk-pixbuf, even if it's
only really meant to be used on "freedesktop" platforms?
- Are there specific API entry points that people need besides the
current API (including ) with async support?
- Do we want to have a first implementation using bwrap (and directly
spawning thumbnailers on non-Linux platforms) and experiment with a
longer-running daemon, or should we implement this first in gnome-
desktop and then carry it over?
gtk-devel-list mailing list