Task #421

store files in XDG-recommended directories

Added by Jim Nelson almost 4 years ago. Updated about 1 month ago.

Status:Fixed Start date:06/24/2009
Priority:High Due date:
Assignee:- % Done:

0%

Category:-
Target version:0.13
Keywords:

Description

store files in XDG-recommended directories

0001-Use-XDG-directories-instead-of-storing-in-HOME.patch - patch (5.7 kB) William Jon McCann, 05/14/2012 11:22 am


Related issues

duplicated by shotwell - Bug #5108: Use XDG directories instead of .shotwell Duplicate 04/23/2012
precedes shotwell - Feature #2889: Generate new thumbnail in startup scan if missing Fixed 11/30/2010

Associated revisions

Revision 7ce2f47e
Added by William Jon McCann about 1 year ago

Stores auxilliary Shotwell files in their XDG recommended locations; closes #421.

History

Updated by Adam Dingle about 3 years ago

  • Target version deleted ()
  • Subject changed from Discuss XDG support to store files in XDG-recommended directories

expanded a bit in an email to the Shotwell mailing list:


http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

instead of put all files into ~/.shotwell, put config files to

$XDG_CONFIG_HOME/shotwell, cache files to $XDG_CACHE_HOME/shotwell, data

files to $XDG_DATA_HOME/shotwell will be better.

$XDG_CONFIG_HOME default is ~/.config

$XDG_CACHE_HOME default is ~/.cache

$XDG_DATA_HOME default is ~/.local/share

it will make your $HOME dir clean, and easier for user to delete what the

don't want, e.g. cache files. just delete ~/.cache, no need to find cache

file in every application dirs.

glib2 provide g_get_user_config_dir(), and python provide pyxdg, vala i

don't know yet.

Updated by Roland Dreier about 3 years ago

For what it's worth, in vala one can use

GLib.Environment.get_user_cache_dir() // $XDG_CACHE_HOME

GLib.Environment.get_user_data_dir() // $XDG_DATA_HOME

I believe shotwell does not use its own config file, so no need to worry about XDG_CONFIG_HOME.

Updated by Andrew - almost 3 years ago

  • Status changed from Open to Review
  • Assignee changed from Anonymous to Andrew -

Hi, I have fixed some of this bug, however, I need to know what the nature of the .shotwell/mimics directory is. What is it? What is it used for? etc.

Updated by Andrew - almost 3 years ago

Also can you tell me the files that would ever end up in .shotwell. I obviously have the data, mimics and thumbs dirs, but if there are some other files that may end up in there I need to know :)

Updated by antistress - almost 3 years ago

For the record there is a conflict between XDG specs and Thumbnail Managing Standard http://jens.triq.net/thumbnail-spec/ regarding thumbs

Thumbnail Managing Standard is followed by GNOME applications for thumbs (Nautilus, F-Spot, gThumb, %(=caps)GIMP%…)

Other files can follow XDG spec

Updated by Adam Dingle almost 3 years ago

  • Priority set to High

@and471,

that's great that you want to take on this project. Here are a few things you should know:

1. Of course, existing Shotwell users have a library in .shotwell. For existing users, I think we don't want to migrate this library to the XDG directories since it might potentially be on another filesystem: some users may have created a symbolic link from ~/.shotwell to some other drive since Shotwell's thumbnail cache may grow quite large. So I think it's best to leave things in place for existing users.

2. Shotwell has a -d option which the user can specify to point to an alternate data directory. We want to keep this option alive. So with your changes, if I type 'shotwell -d foo' then Shotwell should use an alternate data directory with the same structure that the .shotwell directory has today (i.e. subdirectories data, mimics, thumbs).

3. The XDG directory specification specifies three separate directories for configuration, data and cache. For Shotwell, I think the current directories .shotwell/data and .shotwell/thumbs should move into the XDG data directory, and ./shotwell/mimics should move into the XDG cache directory. You asked about the mimics directory. That's where Shotwell writes JPEG versions of each RAW photo the user imports. Shotwell can regenerate those if they are deleted, so I think they can safely live in the XDG cache directory. Shotwell is not yet smart enough to regenerate its thumbnails automatically if those are deleted, so I think that Shotwell's thumbnails should live in the XDG data directory.

Thanks again for your help with this!

Updated by Adam Dingle almost 3 years ago

@antistress: Shotwell has a private thumbnail cache and doesn't share thumbnails with other GNOME applications (see #1086 to learn why), so the Thumbnail Managing Standard is not relevant here.

Updated by antistress - almost 3 years ago

@adam (c#8) : ideally thumbs should not live in XDG data for the same reason that rhythmbox covers belongs to XDG cache and not data : they are not data from the user but data automatically generated by the application. A same set of photos would produce same thumbs without regards to the user.

Storing them to XDG data could be a workaround of course until it is fixed

Separating cache, config & data is the goal of the spec ultimately

Of course i'm not a developper and therefore i only see the theorical thing ;-)

Updated by Adam Dingle almost 3 years ago

Replying to [comment:10 antistress]:

@adam (c#8) : ideally thumbs should not live in XDG data for the same reason that rhythmbox covers belongs to XDG cache and not data : they are not data from the user but data automatically generated by the application. A same set of photos would produce same thumbs without regards to the user. Storing them to XDG data could be a workaround of course until it is fixed

I agree. The ideal would be to have the thumbnails in the XDG cache directory. I hope at some point we can make Shotwell smart enough to regenerate missing thumbnails, at which point we could reasonably store them there.

Updated by Adam Dingle over 2 years ago

  • Priority deleted (High)

Updated by Adam Dingle about 2 years ago

#3459has been marked as a duplicate of this ticket.

Updated by Adam Dingle over 1 year ago

  • Assignee deleted (Andrew -)
  • Priority changed from Low to Normal

Updated by antistress - over 1 year ago

Hi,

Looking at the meta bug for GNOME applications, that's pretty amazing to see that a lot of applications now comply with the spec (see dependecy tree at the btom of https://bugzilla.gnome.org/show_bug.cgi?id=523057 ) !

What is the target version to see that bug fixed in shotwell ?

Thanks

Updated by Adam Dingle over 1 year ago

  • Priority changed from Normal to High

I've just upped this bug's priority to High, but I still think it's unlikely that we at Yorba will be able to fix this for the 0.12 release this spring, unless someone external wants to contribute a patch. We agree this would be a nice change, but we're currently focusing our limited resources on features that are more visible to most users.

Updated by antistress - about 1 year ago

It seems that v0.12 is there (i hope i will soon be able to try it :-)... Maybe this could be planed for 0.13 ?

Updated by Adam Dingle about 1 year ago

  • Target version set to 0.13

We can consider this for 0.13.

Updated by Adam Dingle about 1 year ago

  • Status changed from Open to Review

Thanks for the patch! Lucas, please review.

Updated by Lucas Beeler about 1 year ago

  • Status changed from Review to 5
  • Resolution set to fixed

Fixed in 7ce2f47eaf2b59b72a74943ea6f425cc1d33290b.

Updated by Lucas Beeler about 1 year ago

Thanks Jon!

Updated by Charles Lindsay about 1 month ago

  • Status changed from 5 to Fixed

Also available in: Atom PDF