[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gtk-devel
Subject:    Re: GnomeDesktopThumbnail API replacement
From:       Bastien Nocera <hadess () hadess ! net>
Date:       2018-01-22 16:03:39
Message-ID: 1516637019.3261.86.camel () hadess ! net
[Download RAW message or body]

On Mon, 2018-01-22 at 15:22 +0100, Carlos Garnacho wrote:
> Hey,
> 
> On Wed, Jan 17, 2018 at 6:15 PM, Bastien Nocera <hadess@hadess.net>
> 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>
> > > 
> > > 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?
> > 
> > This is the API that I came up with, which could live in either
> > gdk-
> > pixbuf, or GTK+, dependency-wise. It might also be small enough to
> > copy/paste although I count 15 users of just the C API in Debian
> > Codesearch[1], so it might be worth having in a shared library
> > anyway.
> > 
> > typedef enum {
> > GNOME_DESKTOP_THUMBNAIL_FLAGS_NONE = 0,
> > GNOME_DESKTOP_THUMBNAIL_FLAGS_SAVE,  // Whether to save the
> > created (successful or failed) thumbnail to the cache
> > } GnomeDesktopThumbnailFlag;
> > 
> > #define GNOME_DESKTOP_THUMBNAIL_FILE_ATTRIBUTES                 \
> > G_FILE_ATTRIBUTE_THUMBNAIL_PATH ","                     \
> > G_FILE_ATTRIBUTE_THUMBNAILING_FAILED ","                \
> > G_FILE_ATTRIBUTE_THUMBNAIL_IS_VALID ","                 \
> > G_FILE_ATTRIBUTE_PREVIEW_ICON ","                       \
> > G_FILE_ATTRIBUTE_TIME_MODIFIED ","                      \
> > G_FILE_ATTRIBUTE_STANDARD_FAST_CONTENT_TYPE
> > 
> > // About @info:
> > // NULL means we'll look it up if necessary, otherwise must include
> > // GNOME_DESKTOP_THUMBNAIL_FILE_ATTRIBUTES,
> > // G_FILE_ATTRIBUTE_STANDARD_CONTENT_TYPE will however be used
> > rather
> > // than G_FILE_ATTRIBUTE_STANDARD_FAST_CONTENT_TYPE if present
> > 
> > GdkPixbuf *
> > gnome_desktop_thumbnail_generate_thumbnail_sync
> > (GnomeDesktopThumbnailFactory  *factory,
> > GFile             
> > *file,       // instead of a URI?
> > GFileInfo         
> > *info,
> > GnomeDesktopThumbn
> > ailFlags     flag,
> > char              
> > **ret_thumbnail_path,
> > GError            
> > **error);
> 
> Maybe having both operations split (#1 generating the thumbnail, #2
> loading it as a GdkPixbuf) might help see the layer to which each
> more
> clearly belongs?

I don't think it's really helpful. If you chose not to save the
thumbnail for example (maybe for privacy reasons?), you'd end up with
nothing. This also makes it more difficult to use the macOS APIs, which
just give back an image, and doesn't have any easily accessible caches.

macOS:
https://developer.apple.com/library/content/documentation/UserExperience/Conceptual/Qu \
icklook_Programming_Guide/Articles/QLDrawGraphContext.html#//apple_ref/doc/uid/TP40005020-CH8-SW4


The Windows API requires to save the thumbnail in the cache, if you
want to lookup whether a thumbnail already exists in the cache.

Windows:
https://stackoverflow.com/questions/19523599/how-to-get-thumbnail-of-file-using-the-windows-api


Both the Windows and macOS APIs also seem to use their own image
formats. Will we want to convert those to GdkPixbuf? Or pass them back
as NativeImage opaque pointers for each platform?

> GdkPixbuf generation from a GFile(Info) might easily
> be gdk-pixbuf or gtk+ helpers, thumbnail generation requests might be
> into a separate library, or behind a GIO interface.
> 
> Cheers,
> Carlos
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list


[prev in list] [next in list] [prev in thread] [next in thread]