After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 171171 - choose a better directory for user data on Win32
choose a better directory for user data on Win32
Status: RESOLVED DUPLICATE of bug 166643
Product: GIMP
Classification: Other
Component: libgimp
2.2.x
Other Windows
: Normal enhancement
: 2.10
Assigned To: GIMP Bugs
GIMP Bugs
: 315967 572231 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2005-03-22 04:46 UTC by ungeschlagen
Modified: 2012-10-10 22:22 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description ungeschlagen 2005-03-22 04:46:23 UTC
Distribution/Version: Windows XP

installation
Comment 1 ungeschlagen 2005-03-22 05:46:32 UTC
hello,

that is not a bug, I hope that is not the wrong place for this report.

Every application under windows place his config-data under the directory
x:\documents and settings\<username>\application data\<application>

but gimp place his data under
x:\documents and settings\<username>\.gimp-2.2

that´s a little parasitic *g and discommoding when I make a backup of my config
files.
I can change the place where gimp watch for brushes, patterns, palettes and so
on but I can´t change the directory for many other files. Also I would find it
very discommoding when I have to change all these directorys after installation
per hand.

It would be very fine when you can change this flaw.
Comment 2 Michael Schumacher 2005-03-22 08:52:39 UTC
You can change the location of the personal directory by setting the
GIMP2_DIRECTORY environment variable.
Comment 3 Michael Natterer 2005-03-22 10:55:09 UTC
Perhaps gimp_directory() should use g_get_user_config_dir() on Win32.
Comment 4 ungeschlagen 2005-03-23 03:26:09 UTC
where can I find the GIMP2_DIRECTORY variable?
Comment 5 Michael Schumacher 2005-03-23 09:18:17 UTC
http://support.microsoft.com/kb/310519/de
Comment 6 ungeschlagen 2005-03-23 10:56:02 UTC
Are you a German or knew you that I am so?
In any case it works really good, thank you very much.
Comment 7 Sven Neumann 2005-03-27 20:12:26 UTC
I think Mitch has a point in comment #3. Michael Schumacher, what do you think
about this proposal? Should we do this for GIMP 2.4? Change libgimpthumb as well?!
Comment 8 Michael Natterer 2005-09-11 20:33:36 UTC
*** Bug 315967 has been marked as a duplicate of this bug. ***
Comment 9 Michael Schumacher 2006-05-22 21:39:42 UTC
I don't think that moving the .gimp directory into AppData is the ultimate solution. There are some dirs a user should be able to access, and AppData (being hidden by default) is even a bit harder to get to than the profile directory.

I'd like to see a platform-independent proposal which splits .gimp into a user-visible part (for brushes, scripts, patterns, ...) and an invisible part (gimprc etc). The latter could go into AppData on Windows, but for the moment I'd hesitate to just change the default location.
Comment 10 Raphaël Quinet 2006-05-22 21:48:21 UTC
I am not sure that gimprc is the best example of a file to be hidden.  Some
strange config options may not be visible in the Preferences dialog but can
still be edited in gimprc.  On the other hand, things such as the sessionrc
or parasiterc could be hidden from the user.
Comment 11 Sven Neumann 2006-05-29 16:15:05 UTC
I agree with Michael and that is also what I have discussed with the guys from the Create project.  GIMP should only store its configuration files in the hidden dot directory.  Resource files should be in a user-visible directory and preferably be shared with other applications.

Since this is probably too much of a change for GIMP 2.4, we should look at the simpler proposals that have been made in this bug report.
Comment 12 Sven Neumann 2006-06-27 18:15:49 UTC
It is getting late for a change. If someone understands this issue, it would be nice to get a short summary and a suggestion for changes. Otherwise we will have to move this to the 2.6 milestone.
Comment 13 Sven Neumann 2006-08-15 17:00:29 UTC
Moving to 2.6 because noone came up with a decent proposal yet.
Comment 14 Aurimas Juška 2007-04-13 11:07:07 UTC
Discussion about the same can be found in bug 164075 – Location of settings folder not well chosen for Windows GIMP and bug 335342 – User files are installed to the wrong folder.
Comment 15 Martin Nordholts 2008-05-28 18:34:34 UTC
Without a real driving force behind this change, this bug report just adds noise to specific milestone lists. Putting on the Future milestone list.
Comment 16 Michael Schumacher 2009-02-19 11:54:33 UTC
*** Bug 572231 has been marked as a duplicate of this bug. ***
Comment 17 Jehan 2012-10-10 08:56:43 UTC
I have just submitted a patch on Bug166643 and believe it should basically satisfy this bug report. For Windows, as verified on current Glib development code (2.34.0), the used directory will be CSIDL_LOCAL_APPDATA.

According to Microsoft documentation found on the web, it would usually
correspond to:
C:\Documents and Settings\{username}\Local Settings\Application Data\

It does not deal with data separation though (like brushes, scripts, patterns, etc.), as I read has been discussed above. But I would say that's a first step.

Also I agree that these data could be in a different folder, and even shared, as discussed (for instance GIMP and Mypaint could use the same brushes, etc. Though I have no idea if they use the same brush format). But I don't think the data dir should be visible. Most casual users care as much about brushes, scripts, etc. as the configuration (= nearly not at all); and they probably certainly don't want to see a directory in the middle of their home directory, dedicated to GIMP data.
Power users, those who care about these data, would anyway search for these on the web, the docs, etc. So they would know where to find this directory and add/remove data in it. So it should be hidden.

Moreover checking all conventions, it is a hidden dir in XDG ($XDG_DATA_HOME), in Windows (LocalAppDataFolder), and in OSX (Library dir). I don't think we should go against all these standards.
Comment 18 Michael Natterer 2012-10-10 22:22:32 UTC
Bug 166643 has a patch in progress that is going to fix this
problem too, resolving as duplicate.

*** This bug has been marked as a duplicate of bug 166643 ***