Let's see what freedesktop.org has for us...

 Recent File Storage (implemented, bug #131206)
 Thumbnail Managing Standard (implemented)
 Desktop Entry Specification (implemented)
 Shared MIME Database (bug #131596)
 Drag-and-Drop Protocol for the X Window System (GTK+ makes us use that)
 Clipboards (we follow the advices given here)
 Startup Notification (implemented)
 File URI Specification (we should be following this, did anyone check?)

Bug #166643: Support for the Freedesktop.org XDG variables

GIMP should probably use xdg-user-dirs and add a bookmark for the Pictures folder to the file dialog and perhaps even go there by default:

 http://www.freedesktop.org/wiki/Software/xdg-user-dirs

We could, and probably should, use xdg-utils for some tasks:

xdg-open would be a good default for the command to launch the web-browser.

xdg-email would be a much better choice than sendmail to use from the mail plug-in.

The problem here is that xdg-utils is not yet in widespread use. It might make sense to add a configure option for it. Then distributors could enable support for it.

Bug #41850: Trash should follow fdo trash spec (adds restoring facilities)

The freedesktop trash spec [1] should be implemented.

[1] http://www.ramendik.ru/docs/trashspec.html,
http://www.freedesktop.org/wiki/Specifications/trash-spec 

I think comment #5 was meant to be added to some nautilus bug, no GIMP.

Er, I made the mistake of thinking that the Gimp
had a delete file option.  If it doesn't have one,
we don't need to worry about the trash spec in gimp.

For info, we now support $XDG_CONFIG_HOME (Bug 166643) of the basedir spec, and we support the thumbnail standard too in $XDG_CACHE_HOME (Bug 646644).

I guess our support of XDG is pretty good as of today.

What can be probably improved is more separation between configuration files (*rc files for instance) and user data (brushes, plug-ins, fonts, patterns, themes, etc.) that should probably go in $XDG_DATA_HOME/GIMP/2.9/.
I think it is real good usage to separate between some basic configuration that we may afford to lose and even that one may want to erase on purpose some day to start from a blank state and data that a user took time to build and really cares about (custom brushes or dynamics, etc.).

We decided not to split up GIMPDIR because we tell people all the time
to move it away in order to test stuff.

Hi Mitch,

ok. But when we "test stuff", that's mainly in developing environment, with well aware users. For them this additional complexity won't be that complex actually. "Normal" users won't do this.

But anyway that was only an idea to adhere better to XDG logics and philosophy. It is not that important to me and the way it is now is good enough for the time being. Just saying that this is what it would take to go better/deeper into the spec. :-)

You have a point about proper separation of data and config of course,
but we really tell *normal* users to move the stuff away all-the-time :)
On IRC and in bugzilla.

Hi.

I am one of these *normal* users. :) Currently i setup an Backup Script for all my data via rsync. For me it would be great if all programs use .config and .local for their files. Then i can backup these folders and have what is important without temp files. I know, i can exclude files/folders. But if all programs would use the XDG spec i have less to do or to consider.

Maybe this is a Point to reconsider this.

GIMP 2.9 (git master) keeps its stuff in ~/.config/GIMP. I don't know why
this bug is still open, is anything missing?

I have GIMP 2.8 under ArchLinux (https://www.archlinux.de/?page=PackageDetails;repo=extra;arch=x86_64;pkgname=gimp) and there is still a .gimp-2.8 Folder und ~ If it is change in 2.9 then i just have to wait and this bug is fixed.

Torben > Yes, this is a change in the next major version (2.10) of GIMP (to be accurate, we save in $XDG_CONFIG_HOME/GIMP/{version}, and the XDG_CONFIG_HOME defaults to ~/.config/), since we can't do such major change in a minor version. So you'll just have to wait, and what you wish for will happen. As for now, just bear with your custom scripts a little while longer. :-)

Mitch > Well that's a tracking bug. So it was not only about the config directory. There was the discussion about whether we ever want to separate data from config file for instance. Last status was that we don't want to do it for now, but it might change some day, or can't it? I, for one, would be in definite favor of such a separation if we ever decide to go for it, and would be ok to implement it.

Sven had a few other remarks for improvements above: maybe using xdg-open to select the browser, and xdg-email for mail plugin. Maybe make use of xdg-user-dirs as well...

I can see even a few more separation, as for cache data. For instance the action-history, sessionrc, or pluginrc are for me definite cache data. They are present for convenience or speeding startup (as for pluginrc), but would be regenerated at startup/exit without "real" loss if absent, are neither configuration nor data and should therefore go to $XDG_CACHE_HOME if we want to do things thoroughly.

If we split up that stuff, we will have to start asking people
to move 3 directories away in order to start with a "clean" GIMP.

I don't think the cleaner solution is worth that kind of trouble.

We could however move the stuff that can be safely deleted and
automatically regenerated to $XDG_CACHE_HOME, but sessionrc is
clearly not among these files.

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/74.