Re: GnomeDesktopThumbnail API replacement

[Debarshi Ray]

On Thu, Feb 01, 2018 at 10:33:58PM +0100, Bastien Nocera wrote:
> But we could make some internal changes to that API to allow you to
> pass associated metadata, maybe, so you could do something like:
> - tell the thumbnail API to only consider this private thumbnailer you
> have, and no other
> - find a way to pass 2 files, or maybe one file and a serialised
> string/metadata to the thumbnailer which would do its job.
> 
> There's currently no way to do the 2nd part, but I'll try to see
> whether we can make the API extensible at least, so writing something
> like that is possible.

Ok. Thanks for looking into it.

> > (One thing that I didn't mention so far is that Photos also has
> > online thumbnailers.  They grab server-side generated thumbnails
> > for online content which sometimes requires credentials for the
> > GOA account. Currently these are in-process and are a glorified
> > g_file_copy over HTTP.)
> 
> The thumbnailing processes are sandboxed with no network access right
> now. I don't think that's something we want to change, but it just
> makes it a 2-step process.

Yes, we shouldn't let the local thumbnailers have access to the network.
This is why, currently, the custom local thumbnailer in Photos doesn't
handle online content. The online content is thumbnailed inside the
main application process.

I wonder if it makes sense to split the online thumbnailing into a
second out-of-process thumbnailer that can be sandboxed with a
different set of restrictions. Maybe not? It's a fancy g_file_copy,
so it already goes through GVfs' out-of-process HTTP backend. Maybe
the GVfs' daemons should be seccomp-ed instead?

> [1]: This is the latest attempt, just the sync version:
> PROPERTIES:
> [...]
> - number of threads in the thread pool

Oh, yes, that's another thing that I currently use to prevent the
thumbnailing from clogging up the GTask thread pool.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GnomeDesktopThumbnail API replacement

[Bastien Nocera]

On Tue, 2018-01-30 at 14:45 +, Debarshi Ray wrote:
> On Tue, Jan 30, 2018 at 02:06:01PM +0100, Bastien Nocera wrote:
> > On Tue, 2018-01-30 at 11:06 +, Debarshi Ray wrote:
> > > Also, it's not primarily about the location of the cache but the
> > > thumbnailer. To me, the real value in using the generic
> > > thumbnailers
> > > is not having to worry about all kinds of weird MIME type
> > > problems,
> > > sketchy files, and the various problems that arise from those
> > > things.
> > 
> > What files are you interested in thumbnailing that your application
> > doesn't support?
> 
> It's not about thumbnailing MIME types that the application doesn't
> support, no.  Sorry, I could have been clearer.
> 
> It's about dealing with sandboxing the thumbnailer, dealing with
> CVEs,
> crashes and broken output arising out of weird files, etc..  Some of
> these are potentially fixable at the codec level, which is why I
> mentioned that standardizing around a smaller set of codec
> implementations will also be a win, even if the thumbnailing layer on
> top is different.
> 
> (An example of a weird file would be a panorama generated by a
> Samsung
> Galaxy: https://forums.adobe.com/thread/2131432)

OK. This would however just protect you until the point you open the
image in question, unless you consider the thumbnailer's response to be
authoritative. Much like the existing sandboxing of thumbnailers won't
protect eog or evince itself, just the associated thumbnailers.

But we could make some internal changes to that API to allow you to
pass associated metadata, maybe, so you could do something like:
- tell the thumbnail API to only consider this private thumbnailer you
have, and no other
- find a way to pass 2 files, or maybe one file and a serialised
string/metadata to the thumbnailer which would do its job.

There's currently no way to do the 2nd part, but I'll try to see
whether we can make the API extensible at least, so writing something
like that is possible.

> > > One could imagine asking the generic thumbnailer to thumbnail the
> > > original file, and then have the application run the edits on top
> > > of
> > > it. However, that won't work if the image was cropped because
> > > you'd
> > > have to crop the original thumbnail and then proceed, which will
> > > affect the resolution of the final thumbnail. If I am not
> > > mistaken, I
> > > coded Photos' thumbnailer to load the image at a lower resolution
> > > if
> > > it wasn't cropped, else it loads at full scale and downscales
> > > later.
> > 
> > At this point, you could very well apply the edits and thumbnail
> > internally, as the app would know which one of the photos have
> > edits
> > attached to them.
> 
> Umm... I didn't understand whether you meant that as an alternative
> or
> as something to complement the existing setup.
> 
> I'd like to do what you mentioned above to complement the existing
> setup.  Say you started with an empty cache or you added a new online
> account or whatever, and now you have a large number of items queued
> up for thumbnailing.  Meanwhile, if you open an unthumbnailed item at
> full resolution, then it should be possible to jump the queue and
> create a thumbnail from the hi-res.  It's just nice to do that for so
> many reasons.  Also, if you have a provider that doesn't offer
> server-generated thumbnails, then this can serve as a workaround.
> 
> This is regardless of which thumbnailing API is being used.  For
> example, you can do this for Documents too, which uses the generic
> stuff; and for viewers/players and Files.  Although, it would be
> hindered by every Flatpak having its own thumbnail cache.  Do/will
> they have a shared cache?  Or not?

In Flatpak, no, it's expected that each app has its own cache.

> (One thing that I didn't mention so far is that Photos also has
> online
> thumbnailers.  They grab server-side generated thumbnails for online
> content which sometimes requires credentials for the GOA account.
> Currently these are in-process and are a glorified g_file_copy over
> HTTP.)

The thumbnailing processes are sandboxed with no network access right
now. I don't think that's something we want to change, but it just
makes it a 2-step process.


> > > > > 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", ,
> > > > "tEXt::Thumb::Software::Version", "1.0", NULL);
> > > > is do-able from within the thumbnailer, and that extra metadata
> > > > would be kept.
> > > 
> > > Yes, that's right. It will be good if the generic thumbnailers
> > > would
> > > version their output like that. Maybe it should be added to the
> > > standard?
> > 
> > I'll add a "FORCE" flag to the API. As you'd control 

Re: GnomeDesktopThumbnail API replacement

[Debarshi Ray]

On Tue, Jan 30, 2018 at 02:06:01PM +0100, Bastien Nocera wrote:
> On Tue, 2018-01-30 at 11:06 +, Debarshi Ray wrote:
> > Also, it's not primarily about the location of the cache but the
> > thumbnailer. To me, the real value in using the generic thumbnailers
> > is not having to worry about all kinds of weird MIME type problems,
> > sketchy files, and the various problems that arise from those things.
> 
> What files are you interested in thumbnailing that your application
> doesn't support?

It's not about thumbnailing MIME types that the application doesn't
support, no.  Sorry, I could have been clearer.

It's about dealing with sandboxing the thumbnailer, dealing with CVEs,
crashes and broken output arising out of weird files, etc..  Some of
these are potentially fixable at the codec level, which is why I
mentioned that standardizing around a smaller set of codec
implementations will also be a win, even if the thumbnailing layer on
top is different.

(An example of a weird file would be a panorama generated by a Samsung
Galaxy: https://forums.adobe.com/thread/2131432)

> > One could imagine asking the generic thumbnailer to thumbnail the
> > original file, and then have the application run the edits on top of
> > it. However, that won't work if the image was cropped because you'd
> > have to crop the original thumbnail and then proceed, which will
> > affect the resolution of the final thumbnail. If I am not mistaken, I
> > coded Photos' thumbnailer to load the image at a lower resolution if
> > it wasn't cropped, else it loads at full scale and downscales later.
> 
> At this point, you could very well apply the edits and thumbnail
> internally, as the app would know which one of the photos have edits
> attached to them.

Umm... I didn't understand whether you meant that as an alternative or
as something to complement the existing setup.

I'd like to do what you mentioned above to complement the existing
setup.  Say you started with an empty cache or you added a new online
account or whatever, and now you have a large number of items queued
up for thumbnailing.  Meanwhile, if you open an unthumbnailed item at
full resolution, then it should be possible to jump the queue and
create a thumbnail from the hi-res.  It's just nice to do that for so
many reasons.  Also, if you have a provider that doesn't offer
server-generated thumbnails, then this can serve as a workaround.

This is regardless of which thumbnailing API is being used.  For
example, you can do this for Documents too, which uses the generic
stuff; and for viewers/players and Files.  Although, it would be
hindered by every Flatpak having its own thumbnail cache.  Do/will
they have a shared cache?  Or not?

(One thing that I didn't mention so far is that Photos also has online
thumbnailers.  They grab server-side generated thumbnails for online
content which sometimes requires credentials for the GOA account.
Currently these are in-process and are a glorified g_file_copy over
HTTP.)

> > > > 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 larger version quite some time ago, and somebody would need
> > > to go through the process to make it any bigger.
> > 
> > I see, ok. By larger version, you mean one for 512x512 icons?
> > 
> > I haven't had the occasion to see what a N > 2 display looks like.
> > I can imagine that upscaling 512x512 raw pixels to cover 256x256
> > logical pixels might be passable. It'd still be better than LoPPI,
> > but not better than N=2 HiPPI. I don't know.
> 
> Seems to be 256x256:
> https://specifications.freedesktop.org/thumbnail-spec/thumbnail-spec-latest.html#THUMBSIZE

Oh, you meant Jon added the large 256x256 variant. Ok. :)

I had misread your original email as "Jon drafted a larger version
than 256 some time ago".  Sorry about that.

> Unfortunately, we (GTK+/GNOME) don't control the thumbnail spec. As
> mentioned, any additions would need to go through discussions on xdg-
> list.

Ok.

> > > > 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", ,
> > > "tEXt::Thumb::Software::Version", "1.0", NULL);
> > > is do-able from within the thumbnailer, and that extra metadata
> > > would be kept.
> > 
> > Yes, that's right. It will be good if the generic thumbnailers would
> > version their output like that. Maybe it should be added to the
> > standard?
> 
> I'll add a "FORCE" flag to the API. As you'd control both the
> thumbnailer and how it's called, you could do thumbnail the file, and
> if the version in the GdkPixbuf is too 

Re: GnomeDesktopThumbnail API replacement

[Bastien Nocera]

On Tue, 2018-01-30 at 11:06 +, Debarshi Ray wrote:
> Hey,
> 
> On Tue, Jan 30, 2018 at 10:46:30AM +0100, Bastien Nocera wrote:
> > On Mon, 2018-01-29 at 15:42 +, Debarshi Ray wrote:
> > > 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.
> 
> Yes, that's right. Although, the non-Flatpak case would probably
> linger on for a while?
> 
> Also, it's not primarily about the location of the cache but the
> thumbnailer. To me, the real value in using the generic thumbnailers
> is not having to worry about all kinds of weird MIME type problems,
> sketchy files, and the various problems that arise from those things.

What files are you interested in thumbnailing that your application
doesn't support?

> One could imagine asking the generic thumbnailer to thumbnail the
> original file, and then have the application run the edits on top of
> it. However, that won't work if the image was cropped because you'd
> have to crop the original thumbnail and then proceed, which will
> affect the resolution of the final thumbnail. If I am not mistaken, I
> coded Photos' thumbnailer to load the image at a lower resolution if
> it wasn't cropped, else it loads at full scale and downscales later.

At this point, you could very well apply the edits and thumbnail
internally, as the app would know which one of the photos have edits
attached to them.

> I edited this bit from the blog because it was already getting too
> long. :)
> 
> > > 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.
> 
> I see, ok. By larger version, you mean one for 512x512 icons?
> 
> I haven't had the occasion to see what a N > 2 display looks like.  I
> can imagine that upscaling 512x512 raw pixels to cover 256x256
> logical
> pixels might be passable. It'd still be better than LoPPI, but not
> better than N=2 HiPPI. I don't know.

Seems to be 256x256:
https://specifications.freedesktop.org/thumbnail-spec/thumbnail-spec-latest.html#THUMBSIZE

Unfortunately, we (GTK+/GNOME) don't control the thumbnail spec. As
mentioned, any additions would need to go through discussions on xdg-
list.

> > > 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", ,
> > "tEXt::Thumb::Software::Version", "1.0", NULL);
> > is do-able from within the thumbnailer, and that extra metadata
> > would
> > be kept.
> 
> Yes, that's right. It will be good if the generic thumbnailers would
> version their output like that. Maybe it should be added to the
> standard?

I'll add a "FORCE" flag to the API. As you'd control both the
thumbnailer and how it's called, you could do thumbnail the file, and
if the version in the GdkPixbuf is too old, re-run the thumbnailing
with the "FORCE" flag to force the thumbnail to be re-created.

> However, if all you have is one thumbnailer, then it's just
> convenient
> to version the entire cache and do a "rm -rf" when the version is
> bumped. :)

And is utterly wasteful if you have a shared thumbnail cache, as your
thumbnailer isn't the only one around.

> Also, it can be useful to version the whole cache, if for whatever
> reason, you decide to change its layout. I have been wondering if it
> would be good to add sub-directories for various sources. It could be
> for individual GOA accounts or at the provider level (eg., Flickr).
> It's not essential, but might make it easier or more flexible to
> remove the thumbnails for a disabled account. For the generic case,
> suppose the standard decides to use the actual sizes (ie., 128x128,
> 256x256) as folder sizes instead of "normal" and "large", because,
> you
> know, words like "new" and "large" are kind of risky.  What's beyond
> "new" or "large"? "Shiny" and "huge"? :)
> 
> Anyway, I did it mostly for the convenience.

See above.

> > 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.
> 
> Yeah, I am not really complaining. I understand the fundamental
> problem.  Yes, we are wasting some disk space 

Re: GnomeDesktopThumbnail API replacement

[Debarshi Ray]

Hey,

On Tue, Jan 30, 2018 at 10:46:30AM +0100, Bastien Nocera wrote:
> On Mon, 2018-01-29 at 15:42 +, Debarshi Ray wrote:
> > 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.

Yes, that's right. Although, the non-Flatpak case would probably
linger on for a while?

Also, it's not primarily about the location of the cache but the
thumbnailer. To me, the real value in using the generic thumbnailers
is not having to worry about all kinds of weird MIME type problems,
sketchy files, and the various problems that arise from those things.

One could imagine asking the generic thumbnailer to thumbnail the
original file, and then have the application run the edits on top of
it. However, that won't work if the image was cropped because you'd
have to crop the original thumbnail and then proceed, which will
affect the resolution of the final thumbnail. If I am not mistaken, I
coded Photos' thumbnailer to load the image at a lower resolution if
it wasn't cropped, else it loads at full scale and downscales later.

I edited this bit from the blog because it was already getting too
long. :)

> > 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.

I see, ok. By larger version, you mean one for 512x512 icons?

I haven't had the occasion to see what a N > 2 display looks like.  I
can imagine that upscaling 512x512 raw pixels to cover 256x256 logical
pixels might be passable. It'd still be better than LoPPI, but not
better than N=2 HiPPI. I don't know.

> > 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", ,
> "tEXt::Thumb::Software::Version", "1.0", NULL);
> is do-able from within the thumbnailer, and that extra metadata would
> be kept.

Yes, that's right. It will be good if the generic thumbnailers would
version their output like that. Maybe it should be added to the
standard?

However, if all you have is one thumbnailer, then it's just convenient
to version the entire cache and do a "rm -rf" when the version is
bumped. :)

Also, it can be useful to version the whole cache, if for whatever
reason, you decide to change its layout. I have been wondering if it
would be good to add sub-directories for various sources. It could be
for individual GOA accounts or at the provider level (eg., Flickr).
It's not essential, but might make it easier or more flexible to
remove the thumbnails for a disabled account. For the generic case,
suppose the standard decides to use the actual sizes (ie., 128x128,
256x256) as folder sizes instead of "normal" and "large", because, you
know, words like "new" and "large" are kind of risky.  What's beyond
"new" or "large"? "Shiny" and "huge"? :)

Anyway, I did it mostly for the convenience.

> 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.

Yeah, I am not really complaining. I understand the fundamental
problem.  Yes, we are wasting some disk space and CPU by possibly
thumbnailing the same file multiple times, but that's better than
storing high resolution copies of the edited pixels and thumbnailing
those using the generic APIs because the hi-res copies would be much
larger than the duplicated thumbnails.

(Once we have a decent codec API to load GeglBuffers that can replace
GdkPixbuf for the image viewer/editor and thumbnailer case, it would
already be something because the basic codecs would be more widely
shared.)

But the issues around sizes and versioning can be generally
interesting, and you already covered that.

Thanks for reading!

Cheers,
Rishi
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GnomeDesktopThumbnail API replacement

[Bastien Nocera]

On Mon, 2018-01-29 at 15:42 +, Debarshi Ray wrote:
> On Mon, Jan 22, 2018 at 12:46:51PM +, Emmanuele Bassi wrote:
> > On 22 January 2018 at 09:28, Philip Withnall  > 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", ,
"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
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GnomeDesktopThumbnail API replacement

[Debarshi Ray]

On Mon, Jan 22, 2018 at 12:46:51PM +, Emmanuele Bassi wrote:
> On 22 January 2018 at 09:28, Philip Withnall  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
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GnomeDesktopThumbnail API replacement

[Debarshi Ray]

Hey,

As a heavy user of the thumbnailing APIs, I had promised Bastien to
comment on this thread, but I wanted to coherently compile my thoughts
before doing that.

Some releases ago, I switched GNOME Photos to a custom thumbnailing
infrastructure. I have tried to summarise it here:
https://debarshiray.wordpress.com/2018/01/29/gnome-photos-an-overview-of-thumbnailing/

I don't really expect the desktop-wide thumbnailers to handle the
serialized edits. If possible, great, but otherwise, it's ok, I guess.

However, perhaps, the bits about precise thumbnail sizes versus enums,
and versioning the cache might be interesting?

Cheers,
Rishi
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GnomeDesktopThumbnail API replacement

[Bastien Nocera]

On Mon, 2018-01-22 at 15:22 +0100, Carlos Garnacho wrote:
> Hey,
> 
> On Wed, Jan 17, 2018 at 6:15 PM, 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.
> > 
> > 
> > > 
> > > 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/Quicklook_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

Re: GnomeDesktopThumbnail API replacement

[Carlos Garnacho]

Hey,

On Wed, Jan 17, 2018 at 6:15 PM, 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.
> 
>>
>> 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,
>  GnomeDesktopThumbnailFlags   
>   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? 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

Re: GnomeDesktopThumbnail API replacement

[Bastien Nocera]

On Mon, 2018-01-22 at 12:46 +, Emmanuele Bassi wrote:
> On 22 January 2018 at 09:28, 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.
> > > 
> > > 
> > 
> > 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.

We could return a GIcon/GdkPixbuf. But that doesn't stop it from having
to live in a layer above GIO, where GdkPixbuf is available to the
implementation.

I guess I'll have to dive in and check out the Windows and macOS
thumbnailing APIs.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GnomeDesktopThumbnail API replacement

[Emmanuele Bassi]

On 22 January 2018 at 09:28, 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.
>>
>> 
>
> 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.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GnomeDesktopThumbnail API replacement

[Bastien Nocera]

Hey Philip,

On Mon, 2018-01-22 at 09:28 +, 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.
> > 
> > 
> 
> 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?


> 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
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GnomeDesktopThumbnail API replacement

[Philip Withnall]

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.
> 
> 

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.

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.

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

> > 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,   
>  GnomeDesktopThumbnai
> lFlags flag,
>  char
>  **ret_thumbnail_path,
>  GError  
>  **error);

Seems reasonable, though I assume people will typically use the
*_async() version? The *_sync() version should still have a
GCancellable argument. I agree with using a GFile rather than a raw
URI. 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.

Philip

signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list