That means using the g_get_[system|user]_[config|data]_[dirs|dir]() functions of
glib. Would be nice if they also worked on Win32 - getting the corresponding
dirs  (Application data, ...) in the users profile directory. Do you know if
these functions already do this?

Would be a rather trivial change to libgimpbase/gimpenv.c. I am however not sure
if all the suggestions in the spec make sense. /etc/xdg for example seems to be
an extraordinarily bad idea.

It would be nice to have XDG_DATA_HOME, XDG_CONFIG_HOME, XDG_CACHE_HOME 
variables support.

Let's consider doing this for gimp 2.4.

Since noone has started to work on this yet, we are postponing this change for the 2.6 release.

*** Bug 518595 has been marked as a duplicate of this bug. ***

*** Bug 521118 has been marked as a duplicate of this bug. ***

If this is supposed to be done for 2.6, then someone needs to start working on                       it very soon now. This change will need some testing and not much time is left in the 2.5 development cycle.

I have looked around a bit, and I'm having a hard time telling whether this is a widely accepted specification, or just an idea by a couple of people about how things ought to be done.  I think probably it would be a mistake for Gimp to use these variables unless distros are going to take the responsibility of making sure that they are defined in the most popular shells, and have reasonable values.

Basically the question is, is anybody else following this specification, and if so, what has their experience been like?

well, browing into my .config i can do a nice listing and get:
audacious      ekiga.conf    gtk-2.0   orage     tracker
audacious.old  glade-3.conf  menus     Terminal  xfce4
autostart      graveman      mousepad  Thunar    xfce4-session

so far. Note that audacious.old is a copy i made. Yeah, XFCE is the only major one doing it atm, so ask them :)
However also note that gtk-2.0 is there, which isn't a small player, and didn't the G stand for gtk? :)
(FYI
oliver@valexia ~/.config/gtk-2.0 $ ls
gtkfilechooser  gtkfilechooser.ini
)

It's a freedesktop.org spec, so it's worth nothing I suppose. I tried lobbying over at the FHS and they said they aren't here to set standards, only to document the ones distro's set.

Chicken and egg kinda thing, since distro's tend to follow specs (where possible). Right now, what spec is it to put files in the homedirs root? It's not documented by the FHS, so it's not an official spec either.

It does btw metion the default for the variables (maybe in case they are unset?).

i was about to fill a similar bug report
Glad to see it will be in next release

Since no one started to work on this yet, I very much doubt that it will be in the next release. That could still happen, but only if someone starts to do the necessary changes real soon now.

I have been submitting the same/similar bug reports to several projects, and one interesting reply was that this apparently is supported by glib 2.6. The Dia developer suggested looking into
g_get_home_dir() -> adapted to g_get_user_data_dir()
aswell as g_get_system_data_dirs()

I'm highly unfamiliar with the gimp source code, but if g_get_home_dir() is used here aswell, it could be as simple as this aswell?

To Oliver Schinagl said (comment #13) : "I have been submitting the same/similar bug reports to several projects"

Please could you check if your reports are linked to Bug 140982 – [Tracking] freedesktop.org conformance

Sorry i wanted to write to Oliver Schinagl said to check if your reports are linked to Bug 523057 – [Tracking bug:] Match FreeDesktop directory specs

getting off topic, No I haven't. I didn't know about that bug report :)

What I did is plain and simply, go to my homedir, delete/move a .<something> entry, start the app, if it recreates it in my homedir, instead of .config or the like (some apps already do so properly, so this was also a cleanup on my part) then I'll hunt down bugtrackers and supply a report. I'd be more then happy to link those bugreports, but since that bug you linked seems to imply only gnome apps, and I didn't have gnome until last week. It would be pointless to have many different bug reports here :p

If you want a patch example, I sent one to Gweled :
https://bugs.edge.launchpad.net/ubuntu/+source/gweled/+bug/201509

The patch is pretty explainatory :
http://launchpadlibrarian.net/12617555/xdg_pref.patch

But I don't know if this kind of find/replace will works with gimp. Also, I suppose that all in the current .gimp is not preferences only. Some cache and user data should be carrefully triaged and put in the corresponding XDG folder

Keep in mind that we do have stuff in .gimp which does belong into different places. IMO we need to decide what goes into XDG_DATA_HOME, XDG_CONFIG_HOME and XDG_CACHE_HOME, respectively.

A Gedit developer also wander what to with plugins 
http://bugzilla.gnome.org/show_bug.cgi?id=522848#c4

This is all just asking for a lot of trouble.  The .gimp directory isn't just used by the program, it is commonly used by users to put brushes, patterns, gradients, plug-ins, scripts, etc there directly.  If those directories get shuffled around into unpredictable places, in hidden directories that lie inside other hidden directories, there is going to be a lot of confusion and anger.

Weskagg > Au contraire !

Actually, the .gimp directory is sometimes .gimp, sometimes .gimp-X.X (version number). If you want to backup your data (say your brushes), you have to backup the whole .gimp config but this might not be compatible with another version of gimp. You might think that you use gimpe 2.5 and erase .gimp-2.4, forgetting some brushes you use very rarely. Let say that you simply want to clean up a bit your $HOME because it's the same $HOME for 10 years that you migrated accross computers : Which ones of the thousand .folders will you keep ?

The current situation is plain trouble but it's difficult to see because we are use to it. The current situation is exactly what you called "directories shuffled around into unpredictable places".

With the XDG spec, your brushes will be in $XDG_DATA_HOME/gimp on all systems ! That's a huge win.

Also, you know that for all your apps, simply backuping $XDG_DATA_HOME is enough.

If you have a config problem because you messed up development version/stable version, if you want to reset your preferences to the default for whatever reason : rm -rf $XDG_CONFIG_HOME. All you will loose is simply a few minutes at reconfiguring your desktop according to your taste. Read more here : http://ploum.frimouvy.org/?184-cleaning-user-preferences-keeping-user-data

Of course, migrating to $XDG is not a simple bug to solve. You also have a very valid point about existing data migration and updating the documentation. 

I'm not saying it will be easy to fix nor that it must be a top priority.

Well, the fact that we have to make it easier for users to install scripts and other resources is somewhat unrelated to this. To a user it doesn't really make much difference if they have to copy things to .gimp-2.x or some other hidden directory. The average user simply doesn't know that these directories exist and they should not have to know about it.

Still it's not that easy to implement. Most changes can probably be done in libgimpbase/gimpenv.c. But at least the code that migrates old profiles on a GIMP update would still need to know about the old locations. And of course this change should be well planned and discussed on the gimp-developer mailing-list.

Bug #164075 should also be taken into account, if possible. Perhaps both bugs can be addressed at the same time.

I don't see anyone sitting down working on this soon, setting milestone Future.

*** Bug 657401 has been marked as a duplicate of this bug. ***

*** Bug 675478 has been marked as a duplicate of this bug. ***

Hello,

I have implemented XDG support, by using g_get_user_config_dir() from Glib.

Here is the "new behavior":

- $GIMP2_DIRECTORY environment variable support is unchanged. It is still priority to any of the below rules, and if is a relative path, will still be considered relative to the home directory.

- By default, we will delegate the search of the right configuration directory to Glib's g_get_user_config_dir(), which means, as verified in Glib 2.34.0 code
 * On UNIX-like platforms, the XDG standards is used. It means that, if $XDG_CONFIG_HOME exists, it is used. Else defaults to {home}/.config, where {home} is the user's actual home.
 * On Windows, CSIDL_LOCAL_APPDATA is used, which is the "data directory for locale application". Usually:
C:\Documents and Settings\{username}\Local Settings\Application Data
 * If none of these exists for some environment where the user does not even have a home, it goes to {tmp}/{user_name}/.config/

How the defaults changes for every platform, let's say for Gimp 2.10:

- Linux and other UNIX (except OSX): from ~/.gimp-2.10 to ~/.config/gimp-2.10
(note that we lose the dot)

- Windows: from C:\Documents and Settings\{username}\.gimp-2.9 to C:\Documents and Settings\{username}\Local Settings\Application Data\gimp-2.9
(here losing the dot makes a lot of sense too as it does not mean invisibility on Windows)

- OSX: from ~/Library/GIMP/2.10/ to ~/.config/gimp-2.10.
The current code was using the user Library directory, which is apparently the recommended way. I could check that Glib library does not make any such special treatment for OSX on the other hand. So we will treat OSX as any other UNIX with XDG rules.
If you prefer to keep the special treatment for OSX, just tell me, that's easy to change back (and maybe if that makes that much sense that OSX does not use XDG, we could also patch the Glib).

In any case, g_get_user_config_dir() is a portable way to retrieve the config directory on all platforms, it follows XDG rules, and it fixes both Bug164075 and Bug171171 for the Windows platform as well.

Also I took care that the migration is not broken. Which means that when users will start their brand new GIMP 2.10 and over, it will also search in all the old style defaults for whatever their platform is.

Created attachment 226154 [details] [review]
Implement XDG support.

Also note that this patch does not cover the data separation (brush, etc.) from the configuration. The attached patch only changes the directory emplacement to better defaults for every platform, but keep the current logics (= everything at the same place).

The separation, which is a new feature, could be handled as part of Bug646644.

Thanks that patch looks pretty complete, apart from the OSX part.
I don't see proper handling of the config dir for OSX in glib master.

Also, the patch is not against git master, and it uses // comments,
would you mind to update them?

It would be nice if CSIDL_APPDATA was used on Windows instead of CSIDL_LOCAL_APPDATA - the local variant is only intended for computer-specific files (it's typically used for caches and temporary files - in general things that can be safely deleted).

Created attachment 226182 [details] [review]
Implement XDG support.

Hi,

I didn't know // comments were forbidden (not written in the GIMP coding style from `HACKING` file). Will fix this.

For OSX, indeed glib does not handle OSX at all and will consider it as another UNIX OS. I was not sure if that was a problem (because XDG is a standards aiming at all UNIX OSes).
So anyway I will add back the special OSX case.

Attached the new patch with those fixes, which should be against git master (or else, I do something wrong).

Jernej > I don't really know what is better. When searching a little why glib made this choice, I found Bug659349 where glib's dev basically explains why they don't want CSIDL_APPDATA being the default.

According to them, it can be a security issue, and they take the example of plugins. Not sure if this is what they were meaning, but indeed plugins are often third-party softwares, hence have less security check. We could imagine we don't necessarily want them on the network.
Also I see a tmp/ under my gimp. No idea if it is actually used, but I guess whatever is the content of a temporary directory is not meant to be shared across machines.

In other words, I think this should be considered when we will have more clearly separated all the data which is in this directory: configuration, cache/temporary data, and user data. At least we'll see more clearly.

I'm aware of that explanation, and I don't agree with it. Most Windows programs use only APPDATA, and never LOCAL_APPDATA.

Plugins IMHO aren't a problem - any plugin that gets dropped in the user-specific directory can't have any external dependencies (if it did, the installer would require administrative privileges, and the plugin could've been installed to GIMP's plug-ins directory), and I don't see a security risk either - if the profile is roaming, the administrator can block executables from roaming (or even running from user's profile).

Regarding tmp (I'm not sure what it's used for, but it might be swap), I agree that it doesn't belong in roaming appdata - but on the other hand putting it there wouldn't be too different from a large number of other Windows programs.

I don't know how it works on Windows, but on GNU/Linux, I install software (programs, library, etc.) locally (in my home environment, without admin privilege) all the time. That's what the --prefix is made for in the `configure` step. So I can definitely install a plugin with external dependencies (themselves being system-installed or locally installed) in my home as simple user.
Once again, maybe Windows, it is not possible (but then it would be sad for them and would be a very limited OS), but I doubt it (how do you test programs under development?).

For the tmp/ not being different from other Windows program, I would say that we could go for being better than the average program.

All this said, I don't use Windows. And I don't fully care of the end implementation (still the perfectionist in me cares a little), nor really know what is the best. And I am a pretty new developer to GIMP too.
So if this is the consensus among GIMP developers, I will make the change and make an exception for Windows OSes to use APPDATA instead of the glib call.

The normal installer for Windows only supports system-wide install. It would be possible to make user-only installer, but that doesn't matter for the current discussion.

Some plugins come with their own installer, which again is system-wide (any system-wide installer must not touch user-specific areas, because those areas are not available when another user logs in).

If somebody puts a plug-in to his user's plugin directory, that plugin should not have any external dependencies (other than those that are included with GIMP or Windows itself) - if it does, they should be put in the plugin directory (because that's the only way the plugin will find them). This way roaming will still work. The only case where it wouldn't work would be if the dependencies were installed system-wide - but in that case there's no point in installing the plugin for user only unless you're specifically trying to break something.

I would say let's do it right this time:

OSX: NSApplicationSupportDirectory/GIMP/GIMP_APP_VERSION
WIN: APPDATA/GIMP/GIMP_APP_VERSION
XDG: XDG_CONFIG_DIR/GIMP/GIMP_APP_VERSION

I'll write to the mailing list too.

*** Bug 171171 has been marked as a duplicate of this bug. ***

*** Bug 164075 has been marked as a duplicate of this bug. ***

Michael: ok I'll do it this way. I am doing some freelance work today, and tonight I am taken, so I'll make and publish the new patch later. Probably tomorrow.

Also I had a question about better support of the environment variable in the mailing list. Let me copy the relevant part:

What do we want to do if the environment variable is set:

1) We save directly under this path. Hence we never know if a version
bump (or downgrade) occurred (there can be problems at every
change of version for this user's configuration if ever something a
little more than copy-paste needed to happen).

2) We now make a subdirectory with the version: $GIMP2_DIRECTORY/x.x/.

That is a migration breakage case which was already existing, but with the new path (GIMP/x.x), we have now a chance to fix this.
I would think that we could go with 2). That's a little more work to
detect the situation but that's nicer to the users. What do you think?

If GIMP2_DIRECTORY is set, people are either on crack, or know
what they are doing, or whatever. In any case they are a total
minority and are not a reason to have gimp_directory() not
return the actual folder (which would be a total api break).

I just realize that this bug is about supporting *all* XDG specified
dirs. Well, the world on !classic_unix has bundles anyway and all the
paths are GIMP's private business. On unix, I really don't see the point
of not keeping stuff in e.g. prefix/etc/gimp either. Things have always
been nicely sorted there. we should stick with XDG for cleaning up
the mess in peoples' home directories.

Copy-paste from mailing list, because that's not what I meant and I don't propose an API change/break:

-------------

I must have badly explained, because that's not what I wanted to tell. :-) gimp_directory() will still and always return where stuff is stored. No problem here. Only discussing how to determine this folder when the env variable is set. Basically there are 2 cases:

(1) No environment var set: gimp_directory() will return {conf-dir}/GIMP/2.10/
where {conf-dir} depends on the platform (XDG_CONFIG_HOME on Linux, APPDATA on Win and NSApplicationSupportDirectory on OSX basically).
All good.

(2) the env var is set: until now gimp_directory() would return $GIMP2_DIRECTORY itself.
I propose to return $GIMP2_DIRECTORY/2.10/ instead.
Note that the user is still choosing the root of where GIMP should store the configuration, and all the rest. Simply we add one level in the configuration tree. This way, first we make it consistent with the case (1). Second we can support their configuration migration.

The problem indeed when people set this variable is that when a 2.8 users will use 2.10 for the first time, if he had this variable both before and now, GIMP will not consider the user's configuration to be a 2.8. Hence no migration will happen. In most cases, that should be ok (as the migration is mostly about copy-pasting files and folders). But if something changed and we want to actually do something other than copy-pasting, these users will be the only one where the migration will fail.

I hope this is clear enough this time. But I definitely don't propose to break the return valye of gimp_directory().

Michael: about supporting other XDG dirs, I agree. But I would like to propose to do this in 2 steps. Let's first all move to XDG_CONFIG_HOME.
I will have a look at full XDG compliance later. I'll try and do it soon. :-)

GIMP2_DIRECTORY's main use is not to set the root dir for all of
GIMP's versioned config trees, it's about setting a new folder
for *one* session. If people set that and migration doesn't work,
please let's not care about that case at all.

Whoever sets that globally in their environment is doomed, people
should use it for launcher scripts if they have e.g. two different
2.10 versions in their prefixes for whatever reason.

Michael > Ok.

I have written a patch, but I want to test it on a Windows. I will try with a VM, but I have to install Windows first there.
Just to say that it may take 1 or 2 additional days.

Michael > I spent hours trying to compile all the dependencies for compiling GIMP on Windows. I know I will get there at some point, but maybe there is a shorter way. How do people actually develop on Windows? Is there like a magic formula?
More seriously, I'd be very pleased if anyone had some pointer to set up the minimum dev environment for Windows.
What I did so far is:
- Installed MinGW with MSYS;
- Installed Babl;
- installed the intltool;
- Install pkg-config;

Now I am trying to get glib to compile, because that's apparently necessary for GEGL ("funnily" pkg-config had an internal glib, so I could compile it, but that does not install this internal Glib. Annoying). And I get some errors to deal with.
Aren't there any binary package or something for all these libs on Windows?

I could upload the patch now, but as that includes some new code, I want to make sure it works well (I hate giving untested code).
Also I will probably leave on holiday for 2 weeks, probably from tomorrow. So it means that the patch will wait until then, unfortunately.
But it's on its way!

You should be able to find all dependencies except the latest babl and GEGL at http://download.opensuse.org/repositories/windows:/mingw:/

Michael > ok I have spent a little too much time trying to compile under a Windows VM (which was so so so slow, plus my hard drive being only a SSD, I had many space issue. Windows requires so much space! And there was always another missing dependencies), then I tried cross-compiling, and had a bunch of other problems.

Why I wanted to compile under Windows is that I took some piece of code from glib for the Windows part and I wanted to be sure I did not miss something.

I know that I will manage it if I persevere, but I do a pause because I am tired of Windows. So I propose 2 things:
1/ either I send you the version with OSX + Unix/Linux but unchanged Windows path. And later when I will be in the right mood again, I will try my cross-compiling again and do an additional patch.

2/ either I send you the full version, but I'd like someone to compile and test it under Windows before integration (I would not want my second patch to break the Windows port. :-D).
Thanks!

Hey,

forget my last message! I finally managed to cross-compile! I have a last issue, but I'll send it on the ml to get more answers and not pollute this ticket too much.

Created attachment 228688 [details] [review]
New configuration directory scheme

Attached is the new patch which implements the new config directory scheme as proposed by Michael (Comment 37).
It has been tested successfully on Linux and on Windows 7, both in new installation case (no previous conf directory), and on upgrade case (existing conf directory either using the new scheme or the old/current one).

Not tested under OSX, but this part of the code has hardly been touched, so there should be no problem.

Created attachment 228692 [details] [review]
Compilation warning fix on Windows

While I am at it, attached is a small compilation warning fix on the same file libgimpbase/gimpenv.c (I did not include it in the previous patch because that was not in the new code, so I considered it another defect).

Sorry for uploading this here, but I did not think it was really worth it to make a separate bug report for just moving one line and fix a warning...

Pushed the second patch to master, slightly modified:

commit 5f26f5402e9cfcaf80ca6015db74706c2f5dd308
Author: Jehan <jehan@girinstud.io>
Date:   Sun Nov 11 21:22:17 2012 +0900

    libgimpbase: move g_get_home_dir() to the scope where it's used
    
    Fixes warning: variable 'home' set but not used [-Wunused-but-set-variable]

 libgimpbase/gimpenv.c |   15 ++++++---------
 1 file changed, 6 insertions(+), 9 deletions(-)

Why do you use GIMP_APP_VERSION instead of GIMP_USER_VERSION?
GIMP_USER_VERSION is supposed to be the gimpdir version.

Actually I am not sure why... Is there a doc somewhere which explains the difference between APP and USER version? Right now they have the same value. Are there cases where they may have a different value?

And so should I change it and reupload a new patch? Are there anything else to change?

Hmm docs... :) I just know it's that way *cough*. Please adapt the patch
to do that, and I'll apply and try. Thanks for the effort!

Created attachment 228698 [details] [review]
New configuration directory scheme

New version of the patch using GIMP_USER_VERSION. :-)

Thanks, pushed to master with minor style changes:

commit 60e0cfe55ccdc99500d969ab5e9f8ff5f464b3db
Author: Jehan <jehan@girinstud.io>
Date:   Sun Nov 11 20:20:14 2012 +0900

    Bug 166643 - gimp support for the XDG basedir spec
    
    New configuration directory scheme, consistent across platforms, and
    following standards.
    
    UNIX platforms (except OSX): $XDG_CONFIG_HOME/GIMP/{GIMP_APP_VERSION}
    Windows: %APPDATA%/GIMP/{GIMP_APP_VERSION}
    OSX: NSApplicationSupportDirectory/GIMP/{GIMP_APP_VERSION}

 README                       |    6 +--
 app/core/gimp-user-install.c |   68 +++++++++++++++++++++++-----
 configure.ac                 |    4 +-
 libgimpbase/gimpenv.c        |  132 +++++++++++++++++++++++++++++++-----------------------
 4 files changed, 137 insertions(+), 73 deletions(-)

*** Bug 695623 has been marked as a duplicate of this bug. ***

*** Bug 710526 has been marked as a duplicate of this bug. ***

Things like 'backup' are supposed to go into .config/$XDG_CONFIG_HOME and not in .cache/$XDG_CACHE_HOME as it's not essential (and can grow pretty big by the way). .config is for configuration only according to XDG Base Directory Specification; For good reason: it means that $XDG_CONFIG_HOME stays relatively small with little change over time which makes it easy to backup; $XDG_CACHE_HOME can get lost without major ramifications.

GIMP does *not* support the XDG Base Directory Specification and therefore the issue isn't resolved. Please change the status.

Ah, the other way around; 'backup' is to be considered cache and is therefore supposed to go into $XDG_CACHE_HOME