freedesktop thumbnail spec: modification proposal, central development

[Christian Neumair-2]

Dear xdg list,

I originally wrote this email to Jens Finke and Olivier Sessink (CC),
since both of them wrote the freedesktop.org thumbnail spec. However,
none of them replied so I'm sending it here.


The current thumbnail spec [1] is problematic because it proposed to put
all thumbnails of a certain category (for instance "normal") into one
single directory. However, from a performance point of view it makes
sense to group the thumbnails via parent URI as proposed under [2] in
2007 - so that client applications can tell the OS to pre-load all the
files for a certain directory as it is opened.

Together with that migration, it makes IMO sense to put the thumbnails
into ~/.cache/thumbnails in accordance with the XDG base directory
specification [3], and maybe add a per-directory cache files for storing
the last cached icon size, which would allow file managers and other
users that have a flexible icon layout to calculate their layout BEFORE
having loaded all thumbnails.

Do you plan any such modifications? The fact that the spec is not hosted
on freedesktop.org seems to be a bit unexpected, too. Is there any
particular reason for that?

best regards,
 Christian Neumair

[1] http://jens.triq.net/thumbnail-spec/
[2] http://lists.freedesktop.org/archives/xdg/2007-August/008749.html
[3]
http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

--
Christian Neumair <cneumair@...>

_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Dr. Michael J. Chudobiak]

On 08/07/2009 06:24 AM, Christian Neumair wrote:
> Dear xdg list,
>
> I originally wrote this email to Jens Finke and Olivier Sessink (CC),
> since both of them wrote the freedesktop.org thumbnail spec. However,
> none of them replied so I'm sending it here.
>
> The current thumbnail spec [1] is problematic because it proposed to put
> all thumbnails of a certain category (for instance "normal") into one
...
> Do you plan any such modifications? The fact that the spec is not hosted
> on freedesktop.org seems to be a bit unexpected, too. Is there any
> particular reason for that?

Vincent Untz was looking into getting the original copy of the thumbnail
spec and converting it into docbook, last year [1]. (It was a little
messy, because there was a draft docbook file, but the final spec was
just html). I'm not sure what happened with that... Vincent?

Personally, I wanted the thumbnail spec to be updated to indicate that
image metadata should be respected - especially orientation tags
(mandatory), and ideally (but optionally) things like white balance tags.

Also, the spec should say that "failed" thumbnails should only be
generated if the file was successfully opened (and not, say, if you
didn't have read permissions) and no image could be extracted [2].

I proposed a patch for these two items [3], but it didn't attract much
interest.

[1] http://lists.freedesktop.org/archives/xdg/2008-April/009400.html
[2] http://lists.freedesktop.org/archives/xdg/2008-April/009397.html
[3] http://lists.freedesktop.org/archives/xdg/2008-April/009431.html

- Mike
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Alexander Larsson]

On Fri, 2009-08-07 at 12:24 +0200, Christian Neumair wrote:

> Dear xdg list,
>
> I originally wrote this email to Jens Finke and Olivier Sessink (CC),
> since both of them wrote the freedesktop.org thumbnail spec. However,
> none of them replied so I'm sending it here.
>
>
> The current thumbnail spec [1] is problematic because it proposed to put
> all thumbnails of a certain category (for instance "normal") into one
> single directory. However, from a performance point of view it makes
> sense to group the thumbnails via parent URI as proposed under [2] in
> 2007 - so that client applications can tell the OS to pre-load all the
> files for a certain directory as it is opened.
>
> Together with that migration, it makes IMO sense to put the thumbnails
> into ~/.cache/thumbnails in accordance with the XDG base directory
> specification [3], and maybe add a per-directory cache files for storing
> the last cached icon size, which would allow file managers and other
> users that have a flexible icon layout to calculate their layout BEFORE
> having loaded all thumbnails.
>
> Do you plan any such modifications? The fact that the spec is not hosted
> on freedesktop.org seems to be a bit unexpected, too. Is there any
> particular reason for that?

I don't think anyone in particular is working on this right now, and I
don't have much time atm. But I for sure think its a good idea. The
current scheme is a sore performance issue for many.

If you're interested in working on this and if other people agree that
its a good idea it would be great if you could do this work.


_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Jannis Pohlmann-3]

On Fri, 21 Aug 2009 10:55:52 +0200
Alexander Larsson <alexl@...> wrote:

> On Fri, 2009-08-07 at 12:24 +0200, Christian Neumair wrote:
> > Dear xdg list,
> >
> > I originally wrote this email to Jens Finke and Olivier Sessink
> > (CC), since both of them wrote the freedesktop.org thumbnail spec.
> > However, none of them replied so I'm sending it here.
> >
> >
> > The current thumbnail spec [1] is problematic because it proposed
> > to put all thumbnails of a certain category (for instance "normal")
> > into one single directory. However, from a performance point of
> > view it makes sense to group the thumbnails via parent URI as
> > proposed under [2] in 2007 - so that client applications can tell
> > the OS to pre-load all the files for a certain directory as it is
> > opened.
> >
> > Together with that migration, it makes IMO sense to put the
> > thumbnails into ~/.cache/thumbnails in accordance with the XDG base
> > directory specification [3], and maybe add a per-directory cache
> > files for storing the last cached icon size, which would allow file
> > managers and other users that have a flexible icon layout to
> > calculate their layout BEFORE having loaded all thumbnails.
> >
> > Do you plan any such modifications? The fact that the spec is not
> > hosted on freedesktop.org seems to be a bit unexpected, too. Is
> > there any particular reason for that?
>
> I don't think anyone in particular is working on this right now, and I
> don't have much time atm. But I for sure think its a good idea. The
> current scheme is a sore performance issue for many.
>
> If you're interested in working on this and if other people agree that
> its a good idea it would be great if you could do this work.

Looks fine to me. Not sure we need hashed-normal/ and hashed-failed/
directories because subdirectories inside ~/.thumbnails/normal and
~/.thumbnails/failed wouldn't conflict with the old thumbnail files.

(Personally, I'd like to propose to merge all the failed/
subdirectories into a single directory -- failed/ -- because IMHO the
failed/ concept is just broken. But that's another story.)

  - Jannis


_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Alexander Larsson]

On Fri, 2009-08-21 at 14:13 +0200, Jannis Pohlmann wrote:

> (Personally, I'd like to propose to merge all the failed/
> subdirectories into a single directory -- failed/ -- because IMHO the
> failed/ concept is just broken. But that's another story.)

I think the idea behind it is that each thumbnail creator may support a
different set of types, and if it cannot thumbnail a file and then
creates a global file that stops other implementations from trying it
they wouldn't even try even though they may support it. Of course,
whether you think this is a problem or not is another thing entierly.

We do however need some form of failed reporting so that apps don't keep
trying to thumbnail some broken file over and over.

_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Jannis Pohlmann-3]

On Sat, 22 Aug 2009 13:58:17 +0200
Alexander Larsson <alexl@...> wrote:

> On Fri, 2009-08-21 at 14:13 +0200, Jannis Pohlmann wrote:
>
> > (Personally, I'd like to propose to merge all the failed/
> > subdirectories into a single directory -- failed/ -- because IMHO
> > the failed/ concept is just broken. But that's another story.)

(Err, it's fail/, not failed/ ...)

> I think the idea behind it is that each thumbnail creator may support
> a different set of types, and if it cannot thumbnail a file and then
> creates a global file that stops other implementations from trying it
> they wouldn't even try even though they may support it. Of course,
> whether you think this is a problem or not is another thing entierly.

You say "global" but in reality those are per-implementation files.
GIMP creates fail files in fail/gimp-2.6/, GIO only looks for them in
fail/gnome-thumbnail-factory/ and so on.

I think this is especially problematic with GIO (and probably the KDE
equivalent too) because if someone writes an application that generates
thumbnails, like I did with tumbler, it needs to write fail files to
fail/gnome-thumbnail-factory/ to make GIO's thumbnail::* attributes
work properly.

IMHO the fail/ directory should really contain global files. If
applications need to store information about failed thumbnails that
only they themselves are interested in (as is or could be the case with
GIMP), they should create them somewhere else (e.g. somewhere inside
~/.cache/gimp-2.6).

Might just be me, but I feel that this asymmetry (global
normal/, large/ vs. per-implementation fail/) is problematic.

> We do however need some form of failed reporting so that apps don't
> keep trying to thumbnail some broken file over and over.

Agreed.

  - Jannis


_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Alexander Larsson]

On Sat, 2009-08-22 at 16:14 +0200, Jannis Pohlmann wrote:

> On Sat, 22 Aug 2009 13:58:17 +0200
> Alexander Larsson <alexl@...> wrote:
>
> > On Fri, 2009-08-21 at 14:13 +0200, Jannis Pohlmann wrote:
> >
> > > (Personally, I'd like to propose to merge all the failed/
> > > subdirectories into a single directory -- failed/ -- because IMHO
> > > the failed/ concept is just broken. But that's another story.)
>
> (Err, it's fail/, not failed/ ...)
>
> > I think the idea behind it is that each thumbnail creator may support
> > a different set of types, and if it cannot thumbnail a file and then
> > creates a global file that stops other implementations from trying it
> > they wouldn't even try even though they may support it. Of course,
> > whether you think this is a problem or not is another thing entierly.
>
> You say "global" but in reality those are per-implementation files.
> GIMP creates fail files in fail/gimp-2.6/, GIO only looks for them in
> fail/gnome-thumbnail-factory/ and so on.

When i said global there i meant it as how it would work with global
fail files an how that would then lead to a problem

> I think this is especially problematic with GIO (and probably the KDE
> equivalent too) because if someone writes an application that generates
> thumbnails, like I did with tumbler, it needs to write fail files to
> fail/gnome-thumbnail-factory/ to make GIO's thumbnail::* attributes
> work properly.

I think the problem here is that the GIO thumbnail stuff only does the
reading part of the thumbnail spec, and the fail stuff sort of implies
that each implementation handles the whole spec (i.e. reading +
creating) so that the right fail directory gets used when reading.

> IMHO the fail/ directory should really contain global files. If
> applications need to store information about failed thumbnails that
> only they themselves are interested in (as is or could be the case with
> GIMP), they should create them somewhere else (e.g. somewhere inside
> ~/.cache/gimp-2.6).

This seems a bit simplified. What is it about gimp vs other apps that
implies that gimp should have its own failed directory when others
should not. Yes, your example of tumbler does share the failed directory
with a few other apps (the ones using GIO), but definately not all (for
instance KDE ones).


_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Jannis Pohlmann-3]

On Mon, 24 Aug 2009 10:25:25 +0200
Alexander Larsson <alexl@...> wrote:

> On Sat, 2009-08-22 at 16:14 +0200, Jannis Pohlmann wrote:
> > On Sat, 22 Aug 2009 13:58:17 +0200
> > Alexander Larsson <alexl@...> wrote:
> >
> > > On Fri, 2009-08-21 at 14:13 +0200, Jannis Pohlmann wrote:
> > >
> > > > (Personally, I'd like to propose to merge all the failed/
> > > > subdirectories into a single directory -- failed/ -- because
> > > > IMHO the failed/ concept is just broken. But that's another
> > > > story.)
> >
> > (Err, it's fail/, not failed/ ...)
> >
> > > I think the idea behind it is that each thumbnail creator may
> > > support a different set of types, and if it cannot thumbnail a
> > > file and then creates a global file that stops other
> > > implementations from trying it they wouldn't even try even though
> > > they may support it. Of course, whether you think this is a
> > > problem or not is another thing entierly.
> >
> > You say "global" but in reality those are per-implementation files.
> > GIMP creates fail files in fail/gimp-2.6/, GIO only looks for them
> > in fail/gnome-thumbnail-factory/ and so on.
>
> When i said global there i meant it as how it would work with global
> fail files an how that would then lead to a problem
>
> > I think this is especially problematic with GIO (and probably the
> > KDE equivalent too) because if someone writes an application that
> > generates thumbnails, like I did with tumbler, it needs to write
> > fail files to fail/gnome-thumbnail-factory/ to make GIO's
> > thumbnail::* attributes work properly.
>
> I think the problem here is that the GIO thumbnail stuff only does the
> reading part of the thumbnail spec, and the fail stuff sort of implies
> that each implementation handles the whole spec (i.e. reading +
> creating) so that the right fail directory gets used when reading.
>
> > IMHO the fail/ directory should really contain global files. If
> > applications need to store information about failed thumbnails that
> > only they themselves are interested in (as is or could be the case
> > with GIMP), they should create them somewhere else (e.g. somewhere
> > inside ~/.cache/gimp-2.6).
>
> This seems a bit simplified. What is it about gimp vs other apps that
> implies that gimp should have its own failed directory when others
> should not. Yes, your example of tumbler does share the failed
> directory with a few other apps (the ones using GIO), but definately
> not all (for instance KDE ones).

Exactly, and IMHO that's the problem. (BTW, I'm not saying GIMP should
have its own fail directory unless it's really needed.) Any
thumbnailing implementation, be it GnomeThumbnailFactory,
ThunarVfsThumbFactory, GIMP's libgimpthumb, hildon-thumbnailer or
tumbler are supposed to store fail files in their own directories.

I agree that at a first glance, this might sound reasonable. But if GIO
only picks the fail files from ~/.thumbnails/gnome-thumbnail-factory/,
and KDE only picks up the files from ~/.thumbnails/<insert KDE
directory here>/ this implies that implementations that aim to support
all VFS layers and applications properly will have to create fail files
in all these directories.

IMHO that's not very useful and it sounds like a violation of the spec
to write to all those directories from a thumbnailing implementation's
POV.

Now that we're adopting GIO everywhere inside Xfce, I'd be
very happy to see many of the (luckily few) now-hardcoded bits in GIO
(and also other VFS implementations and applications) transformed into
standards.

This also applies to preferred applications (e.g. GIO only checks a few
common terminal emulators for the Terminal= key of .desktop entries
because there is no standard for preferred applications yet), just to
provide another example.

  - Jannis


_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg