GNOME Bugzilla – Bug 592566
GIMP 2.4.7 creates a directory gegl-0.0 inside my MyDocuments folder
Last modified: 2011-04-04 16:13:23 UTC
Ever since I upgraded to GIMP 2.4.7 from 2.4.6, GIMP has been creating a folder gegl-0.0 inside my MyDocuments folder everytime I start even. This folder only contains a folder plug-ins which only contains a file Makefile. This clutters my MyDocuments directory and is also meaningless. If GIMP really needed a temporary directory, it should allow me to configure where to put it. Otherwise, this empty directory should not be created. Please fix this. Working on Windows XP SP 3.
This isn't a temporary directory.
Right, but I should be allowed to change it. I don't want GIMP cluttering up my MyDocuments folder.
Sorry for the extra post, but I forgot to mention that I don't even use GEGL directly. All I know about it is that it is a newly developed library which GIMP uses. Why should I care about it when I don't have any particular need of using it? So I don't want to see it in my MyDocument folder.
For the time being, you just have to decide which one is more important to you, using GIMP or not having to see such a folder. Sure, it would be a good idea to eventually avoid creating this folder, especially on Windows, unless it actually is needed. Especially the plug-ins/Makefile is of course totally unnecessary and pointless to the vast majority of end-users on Windows who are never going to build any GEGL plug-ins themselves.
Just found out about this, and putting anything in Documents without user's consent is a very bad thing to do (and just because several other programs do the same, it doesn't make it right). It's also ironic that while gegl can abuse user's Documents folder, GIMP still doesn't store it's settings in the correct directory on Windows.
I support the request of Shriramana Sharma with emphasis. Creating meaningless folders outside of Gimps directory tree is a mess. Ben
Then have a look at the GEGL source code and remove the creation of this directory and attach a patch to this bug? This can't be too complicated, someone just has to do it.
Confirmed, the same happens to me, and it is annoying.
See comment #4. With emphasis.
The folder is also present on Linux in ~/.gegl-0.0 I have made a notice on http://live.gnome.org/GnomeGoals/XDGConfigFolders (Gimp) I think this should also block Bug 523057 Somewhere I read that this is fixed in 2.6.9 but could not find any confirmation, maybe someone can clarify this? Cheers Sebastian
Sure, but on Linux (and POSIX systems in general) such folders are rarely seen as bothersome even in those cases where they don't contain anything actually used, because as I am sure you know, files and folders with names starting with a dot are not normally shown in directory listings, and especially in the home directory, there are a whole lot of such folders, and few people bother to even keep track of what software creates and uses them.
I dont agree. While you are right that many programs save their config files in a hidden folder in the home directory this is not actually the place to put these files, they should rather be put into one of the three XDG folders which are: XDG_CONIFG_HOME (for config files) XDG_CACHE_HOME (for temporary and cache files) XDG_DATA_HOME (for user files that are not ment to be accessed directly by the user, e.g. email). There is also a FreeDesktop Spec for this, and many programms have already implemented this or are currently implementing it. Putting everything into the home folder turns the home folder into a huge mess thats difficult to clean up, and even more important, there is no separation between config, data and cache files which makes it difficult to reset an application to default settings or troubleshoot it. For example user often experience bugs that are difficult to be reproduced, since they are caused by incorrect/deprecated settings in the home folder. In such a case it is not even possible to recommend to the user that he deletes the respective folder because he might risk dataloss.
Maybe, but if you want this bug to be more general and cover POSIX systems, too, you should change the Summary and OS fields.
And the best way to solve this is to attach a patch to the bug, after discussing what exactly should be done. This discussion should happen on the gegl-developer mailing list
I think the actual problem is in GLib - gegl calls g_get_user_data_dir, which on Windows returns path to the Documents folder, although (given it's description), AppData would be more appropriate.
*** Bug 631965 has been marked as a duplicate of this bug. ***
I have seen this bug too, but why should this one line be bothersome in a anyway superfluous directory? I have no use for anything like «My folders» and have all of these resources and profiles etc on a separate and easy to maintain partition, which I can save automatically every day. I think such a discussion is absolutely fruitless and wish the efforts of the developers should not be compromised for such trivial small problems. Once all the important bugs have been resolved, then Yes, why not.
Wow! Comeon. Just because this bug doesn`t disturb you doesn`t mean it doesn`t disturb others. This bug really bugs me since months. And this bug gets ignored since over a year now from what i can see. I work with the content of My Documents. And every time i fire up Gimp i need to delete this folder afterwards. Sometimes i forget it or overlook it, and then this folder even makes it into my backups, spreading around at my system. Yeah, gegl-0.0 folder everywhere. This is very bad behaviour. And for me this one is an important bug because it costs my time. This bug is simply annoying. Besides that, every bug should be worth a fix. Ten small bugs can be more disturbing than one big one. I am sure that this one would be a quick fix. It`s "just" changing a path. I would fix this bug when i could. The problem is, i am no programmer, just a Gimp user. I have no clue about C or C++, no idea what to do to fix this bug.
Re-assigning the bug to glib; the path returned for g_get_user_data_dir () seems inconsistent with the XDG Base Directory specification and the expectations of users on win32.
Of course, the XDG Base Directory "specification" (a very short document, and not really very formal) hardly is relevant on Windows. It does not mention Windows at all. (Not that it mentions Unix, POSIX or Linux, either, but that is intended to apply to mainly Linux can be assumed, I guess?) The g_get_user_data_dir() function is *documented* to return the CSIDL_PERSONAL folder. Now, I admit that this documentation was not agreed upon first by some kind of consensus and then the function implemented to do it, but the other way around. As most new API in the GTK+ stack, what it should do on Windows is just a quick guess at first, and seldom does anybody complain until long afterwards. Still, it has been documented like that for a long time (since 2.6), and it is quite possible that there is code out there that uses g_get_user_data_dir() in such a way that the correct return value *is* the CSIDL_PERSONAL folder. Anyway, shouldn't gegl use g_user_get_config_dir()? That *does* return the CSIDL_APPDATA folder on Windows.
The function exists since 2.6, it's win32 platform specific behavior was first documented 2010-06-06. The directory in question can per user plug-ins which I would consider "application data" rather than "application configuration information" which is what g_user_get_config_dir() is documented to be.
>>and seldom does anybody complain until long afterwards. Maybe they all gave up complaining? Not the first time that i personally was told not to bother the developers with bug reports when i tried to talk about it at a gimp board. Also possible that this bug is more rare than i think, and is just visible at Windows XP (german XP home, SP3 here). And maybe even just visible at a german XP version. I was at least told that this problem does not occur at Windows 7. Anyways, thanks for having a look at this problem again :)
> Maybe they all gave up complaining? No, it's more like software packagers often use quite outdated versions of GLib or GTK+ in what they distribute to end-users, so by the time some new API finally is in the hand of end-users of one software, and they start complaining that the API in question does an odd thing on Windows, other software that has been distributed with more up-to-date versions, might already be used to that odd thing, so changing the behaviour would then cause a regression in that other software. GIMP is not the only software using GLib. In this particular case of gegl, maybe use g_get_user_config_dir() on Windows and g_get_user_data_dir() otherwise would be a good idea?
Sounds good. But as told, i don`t really have a clue about programming :)
Related: bug #620710 : Use CSIDL_APPDATA instead CSIDL_PERSONAL in g_get_user_data_dir()
Marking as duplicate of that other bug, as it has more insightful discussion. And congratulations to the reporter: it seems that I have been convinced to change to use CSIDL_LOCAL_APPDATA instead of CSIDL_PERSONAL. *** This bug has been marked as a duplicate of bug 620710 ***
Thank you very much for the fix :)
Actually, I wonder, should we un-duplicate this bug and retitle it now to concentrate on the uselessness and not location of the directory?
Being able to have a location that is scanned for additional per user plug-ins doesnt seem useless to me, even on win32.
This has not been resolved. I have tested 2.6.11 32-bit and 2.6.10 64-bit for Windows 7. In the former case, a "gegl-0.0" folder appeared in "My Documents". In the latter case a "gegl-0.1" folder appeared. This is very annoying. Please, please fix this.
(In reply to comment #30) > This has not been resolved. Do you use glib 2.28?
(In reply to comment #31) > (In reply to comment #30) > > This has not been resolved. > > Do you use glib 2.28? I am using whatever comes bundled with GIMP. Is that too old?
(In reply to comment #31) > (In reply to comment #30) > > This has not been resolved. > > Do you use glib 2.28? On closer inspection, it seems that the Glib which comes bundled with Gimp is 2.24.2.
Fixed in glib 2.28, hence it IS resolved.
I noticed that GLib now uses CSIDL_LOCAL_APPDATA - is there any reason to choose that over CSIDL_APPDATA?