Hey, I wanted to start a discussion about replacing GnomeDesktopThumbnail with an API that would live in the GLib/GTK+ stack.
Why --- 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. The API ------- This is the current API: https://git.gnome.org/browse/gnome-desktop/tree/libgnome-desktop/gnome-desktop-thumbnail.h 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. Implementation -------------- 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. The questions ------------- 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 [1]) 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? Cheers [1]: https://bugzilla.gnome.org/show_bug.cgi?id=684026 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list