Bug 319528

Thank you for your report.

I see a couple of issues with this request.

First and for most, KIO is not the place that decides where thumbnails are stored. That is in the application's hands. So for that one alone i'd recommend you to try and ask the apps that actually make the thumbnails (dolphin, gwenview, ...)

Second, that spec is kinda enforcing when it comes to thumbnail image format. It enforces png. Png is a fine image codec, but better (which are faster and smaller) are popping up. Webp is such a codec along with the in house kde developed codec: "ez".

Third, kde has it's own image caching mechanism for thumbnails that most other kde apps are using as well. That is the "KImageCache" class if i'm not mistaken. So you don't need to worry much about double thumbnails.

Good luck!
Closing this one since it's not up to kio where the thumbnails go.

Mark, even if KDE does not save thumbnails to ~/.cache/thumbnails, it should at least try reading from this location to show thumbnails generated by other applications.

(In reply to comment #2)
> Mark, even if KDE does not save thumbnails to ~/.cache/thumbnails, it should
> at least try reading from this location to show thumbnails generated by
> other applications.

Hi Christopher,

That's true as well, but where should that be done? In the end application or in kimagecache?

BTW. How is EZ progressing?

Regards,
Mark

Are you confusing KImageCache and thumbnail cache? They are unrelated, and that's why I consider this feature request valid.

And unless you are willing to discuss format changes with the X Desktop Group, we should respect that it mandates PNG files.

> How is EZ progressing?

If you mean IZ, no public commits since its announcement, due to lack of interest. I had hoped to attract digikam or Krita developers.

(In reply to comment #4)
> Are you confusing KImageCache and thumbnail cache? They are unrelated, and
> that's why I consider this feature request valid.

Oke, seems i was mixing things up quite massively. I completely mis-read the bug report (i blame my ipad :p) The reporter was right and i was wrong.

KImageCache is indeed not used for thumbnails. Rather it's used for icon caching.

But this did left me wondering: "Where are those thumbnails being generated at the moment?" Since dolphin isn't doing that on it's own: http://quickgit.kde.org/?p=kde-baseapps.git&a=blob&h=eaaab6bc0529f1f72a2bc81ea3b1cd3729f8280b&hb=cab86c292b530ae52c504124e9c77af96cef7f01&f=dolphin%2Fsrc%2Fkitemviews%2Fkfileitemmodelrolesupdater.cpp the only caching it seems to rely upon is the PreviewJob cache.

So upon further investigation in PreviewJob it quickly became clear to me that PreviewJob is managing this. Only not in the .cache folder.

So my earlier statement that KIO is not the place to decide this is false since PreviewJob is doing this.
Also for my own question where this should be done.. PreiewJob apparently ;)

To conclude:
Currently: ~/.thumbnails is used
Needs to be: ~/.cache/thumbnails

Obviously changing bug report from wontfix to verified and remind. I will take care of this issue now. I have the tendency to forget bug reports so if you don't see progress within ~2 weeks, please do remind me! :)

It seems as simple as changing:
    d->thumbRoot = QDir::homePath() + QLatin1String("/.thumbnails/");
to:
    d->thumbRoot = QDir::homePath() + QLatin1String("/.cache/thumbnails/");

> 
> And unless you are willing to discuss format changes with the X Desktop
> Group, we should respect that it mandates PNG files.
> 
> > How is EZ progressing?
> 
> If you mean IZ, no public commits since its announcement, due to lack of
> interest. I had hoped to attract digikam or Krita developers.

Yet another thing i mixed up :( i meant IZ indeed. I hope the interest gets back in that project since it seems very promising!

> Needs to be: ~/.cache/thumbnails

I hope you don't just change it to ~/.cache/thumbnails. If it was that simple, I had changed it right away :)

First read http://specifications.freedesktop.org/thumbnail-spec/thumbnail-spec-latest.html#DIRECTORY to understand what you are doing.

Then check if there is a Qt or KDE way to get the $XDG_CACHE_HOME directory. I know there is.

Additionally, it should be discussed if there should be done something to move the old contents over to the new directory, or at least if the old directory should be cleared or even removed. Check how GNOME did the migration.

Thanks for looking at this.

(In reply to comment #6)
> > Needs to be: ~/.cache/thumbnails
> 
> I hope you don't just change it to ~/.cache/thumbnails. If it was that
> simple, I had changed it right away :)
> 
Yeah, i wasn't expecting it to be that easy :)

I'm sorry, I made a patch for this bug 3 months ago but I forgot to post the link to the review request here.
https://git.reviewboard.kde.org/r/110388/

It's a very trivial patch, but I still want a review because this might cause hidden breakage.
And with everybody focusing on frameworks there has been no response yet.

Sorry for the duplicated effort.

I guess i'm happy i forgot about this bug then :) No wasted duplicated effort.

Hi,

I was wondering how this report was going. I did not actually test it, but from a basic review of Maarten De Meyer's patch, it looks good to me. Well at least if "cacheDir.isEmpty()" means that the environment variable (here $XDG_CACHE_HOME) "is either not set or empty", which I guess it does. :-) Though if KDE/QT had a more high level way to get the XDG cache home (glib for instance has the function g_get_user_cache_dir(), so that programs don't have to redo the environment variable test logics themselves each and every time), it would be nicer. Is there no equivalent function?

As for doing something with the old contents, I'd say that no program can know if another program is still using it. So deleting/moving the old contents is counter-productive if you lose all the thumbnails for a third party, which will have to create again this old directory and all its future thumbnails. That's mostly to users to delete it manually and explicitly. Maybe what could be done though is to move old contents, then transform the empty old $HOME/.thumbnails into a symbolic link to $XDG_CACHE_HOME/thumbnails. This would avoid contents duplication, but has a drawback: if the user were to change its $XDG_CACHE_HOME and move all contents, the old directory would become a broken link, which at best would redo the contents duplication issue, and at worst would prevent some programs from creating thumbnails (because they can't create them into a broken link, and if they don't force the overwrite, they may not be able to recreate the old directory). So I'd say that even this should be up to the knowledgeable user to set up.

> Though if KDE/QT had a more high level way to get the XDG cache home (glib
> for instance has the function g_get_user_cache_dir(), so that programs don't
> have to redo the environment variable test logics themselves each and every
> time), it would be nicer. Is there no equivalent function?

There is for Qt5:
http://qt-project.org/doc/qt-5.0/qtcore/qstandardpaths.html#standardLocations

I always planned to write a similar patch for frameworks using qstandardpaths. But since the other change never shipped I haven't gotten to it yet.
Thank you for reminding me.

Small update:
While planning to make a patch for frameworks I found it's already done. Awesome!
It's a bit of a hassle to find the commit in the new git repo but the code is there.

From my point of view this bug is fixed. I see no reason to backport this.

ps Bug triagers, what is the workflow for bugs that are only fixed in frameworks? Do we keep them around?