#15 Gimp 2.6.7p3: gegl module_path created in ~/.local/share

closed-fixed
nobody
None
5
2010-01-26
2009-11-14
~suv
No

Issue:
When launching Gimp.app the directory for the gegl plug-ins is created in
"$HOME/.local/share/Library/Application Support/Gimp"
instead of
"$HOME/Library/Application Support/Gimp"

Cause:
The current patch (rev. 62) for 'gegl/gegl-init.c' doesn't work as expeced - 'g_get_user_data_dir' returns '~/.local/share' according to the XDG Base Directory Specification: «If $XDG_DATA_HOME is either not set or empty, a default equal to $HOME/.local/share should be used.»

Related links:
<http://www.gtk.org/api/2.6/glib/glib-Miscellaneous-Utility-Functions.html#g-get-user-data-dir>
<http://standards.freedesktop.org/basedir-spec/latest/ar01s03.html>

Possible fixes:
a) add 'export XDG_DATA_HOME="$HOME"' to 'Contents/Resources/bin/gimp'
b) add 'export XDG_DATA_HOME="$HOME/$GIMP2_DIRECTORY"' to 'Contents/Resources/bin/gimp' and change the patch for 'gegl/gegl-init.c' for the module_path from "Library/Application Support/Gimp/gegl" to "gegl".

Notes:
Variant a) could have unintended consequences as XDG_DATA_HOME could be picked up by other plugins or XDG aware libs whereas variant b) would contain any potential file or directory creation inside the $GIMP2_DIRECTORY.

Tests:
I have tested and confirmed variant a), I can't however test variant b) myself because I don't have the build environment for GIMP set up.

System information:
Mac OS X 10.5.8 (9L30)
XQuartz 2.4.0 (xorg-server 1.5.3-apple14)
GIMP 2.6.7p3 for Mac OS X Leopard
build by GIMP on OS X, http://gimp.lisanet.de
Sa 14 Nov 2009 03:07:22 CET

Discussion

  • Simone Karin Lehmann

    THX for your work.

    You're right. Setting XDG_DATA_HOME="$HOME" might have some influence on other libs and plugins. SXDG_DATA_HOME="$HOME/$GIMP2_DIRECTORY" seems to work well, but still there may be some side effects. The 'shared-mime-info' package might be influenced and will search it's data in XDG_DATA_HOME.

    If we go back to the previous setup, and still let XDG_DATA_HOME be empty, we should have a, let's call it, well known setup, that's stable and running. And then we'll have time to dive more deeper into this issue and check if other libs or plugins will rely on XDG_DATA_HOME.

    This could be achieved by setting the module path in 'gegl-init.c' to "../../Library/Application Support/Gimp/gegl", so we get the path "$HOME/.local/share/../../Library/Application Support/Gimp/gegl" which is exactly the same as in previous releases "$HOME/Library/Application Support/Gimp/gegl"

    What do you think about this?

     
  • ~suv

    ~suv - 2009-11-19

    some loosely connected thoughts:

    1) Your solution to keep all XDG paths with default values and reference "$GIMP2_DIRECTORY" with relative path names makes sense and I can't think of a situation where "../../" could fail.

    2) I didn't notice the other XDG path that is used for the gegl swap directory (same issue: instead "$GIMP2_DIRECTORY/gegl/swap" gegl(GIMP) currently writes to "$XDG_CACHE_HOME/Library/Application Support/Gimp/gegl/swap" which expands to "$HOME/.cache/Library/Application Support/Gimp/gegl/swap")

    3) I wanted to read more about 'gegl' by its authors and hoped to find their intentions regarding the XDG basedir spec, but its website currently unreachable... :(

    My question for gegl would have been: what if you changed the patch for gegl-init.c to replace
    g_build_filename (g_get_user_cache_dir(),
    with the previously used
    g_build_filename (g_get_home_dir(),
    which AFAICS should not cause any problems for gegl als long as it later references the swap/config paths consistently with $GEGL_SWAP and $GEGL_PATH.
    <http://git.gnome.org/cgit/gegl/tree/gegl/gegl-init.c>

    4) OTOH isn't the rationale of the XDG basedir specification exactly to allow applications to adapt the default locations of system / user config, data and cache directories while still following an agreed-upon convention?

    Think of other software projects like for example portable applications, running from an USB stick, which need to keep all related (system and user) configuration and data files stored on the stick instead of writing it to '/usr/local/share', '/opt/local/share' or "$HOME". They'd just need to set the environment variables $XDG_{CONFIG|DATA|CACHE}_{DIRS|HOME} before launching the app while the source code itself would not need to be modified.

    5) regarding 'shared-mime-info' - don't you include it already in the package? How is it found by the gtk-loader-modules - hard-coded path at compile time to the link in '/tmp/skl'?

    [ sidenote: Inkscape.app includes the 'shared-mime-info' as well - at same location inside the bundle - and sets "export XDG_DATA_DIRS="$TOP/share" in the launcher script - OTOH it respects the unchanged XDG convention for the user config/data/cache files - and doesn't yet follow Apple's convention to use $HOME/Library instead of dot(files|dirs). ]

    6) One could interpret the XDG basedir structure for GIMP on OS X using the OS X convention to store (system and user) config|data|cache like this:

    System config: /etc/xdg (or /opt/local/etc/xdg ?)
    System data: /tmp/skl/Gimp.app/Contents/Resources/share
    User config: $HOME/Library/Preferences
    User data: $HOME/Library/Application Support
    User cache: $HOME/Library/Caches

    But this would result in reorganizing/splitting the current 'Gimp' folder "$GIMP2_DIRECTORY" and might be discussed for a later GIMP version (2.8?) - if at all to be considered ;-).

     
  • Simone Karin Lehmann

    to follow your ordering...

    1) I've patched gegl-init.c with the relative path ../../Library/Application Support/Gimp and ran a test.
    So far, gegl created it's directories in GIMP2_DIRECTORY, but still creates './local/share' and '.cache' too. This is because the path isn't expanded/collapsed by the routines but taken literally and walked through :-(

    2) the gtkfilechooser widget places its configuration in XDG_CONFIG_HOME, which defaults to '~/.config'.

    4) yes you're right about the XDG basedir specification, although in case of GIMP, the situation slightly differs.

    As long as we stick to strictly follow the MacPorts policy - include all binaries and libraries, even if they already exist on the system - everything will be fine. GIMP will be a jail rooted system with ${prefix} as the system root. Bins and libs outside the jail won't be used. We could set XDG_{DATA|CONFIG|CACHE}_HOME to GIMP2_DIRECTORY.

    As you might have already noticed, GIMP on OS X tries to use a few more already installed libs than providing its own copies. In case of X11 this was true since the very beginning. Current builds use some more system bins and libs: zlib, bzip2 and python. The build process uses the system perl interpreter, ncurses and others. And I'm trying to get even more system bins/libs to be used as well (expat, fontconfig, freetype, cairo and maybe a few more). If we only set XDG_* this might interfere some of those system libs and bins, at least at run time.

    So this will lead us to

    6) IMO that's just the best solution. MacPorts already uses this approach to set the default system data path in glib2 to ${prefix}/share (and that's why GIMP can load shared-mime-info by default and Inkscape needs to set XDG_DATA_DIRS)
    I've just patched glib2 and commited to SVN ('glib/gutil.c') to use default locations inside GIMP2_DIRECTORY for XDG_{DATA|CONFIG|CACHE}_HOME. The patch to 'gegl-init.c' could be dropped and 2) will be solved as well.

    Putting all into GIMP2_DRECTORY has the advantage, that if a user wants to delete GIMP, he only has to delete the app bundle itself and the GIMP2_DIRECTORY.
    OTOH, splitting GIMP2_DIRECTORY would recommend to patch GIMP's sources (or maybe 'gimprc') to use the new locations. And to not break up existing installations - think of user installed scripts, brushes or patterns - we would need to implement some backward compatibility code and write documentation about this different specification as most GIMP documentation out there assumes everything in '~/.gimp-2.6' or GIMP2_DIRECTORY. So IMO it's best to use GIMP2_DIRECTORY, unless we find some other solution...
    BTW, I've just noticed that I didn't patch the default for XDG_CONFIG_DIRS, which IMO should be set to '${prefix}/etc'

    What do you think?

     
  • ~suv

    ~suv - 2009-11-30

    > 2) the gtkfilechooser widget places its configuration in XDG_CONFIG_HOME,
    > which defaults to '~/.config'.

    Noticed as well. Changing its location might need a migration script with the next update or patched version though, unless users don't mind to loose the 'Open Recent' list.

    > 4) about the XDG basedir specification

    I have to trust you on this one ;-) but it makes sense as far as I can follow the details by browsing the SVN repository of gimponosx, without having set up a local build environment / MacPorts tree dedicated to 'gimponosx' and without having built & bundled GIMP myself.

    > 6) set the default system data path in glib2

    Seems well thought out to me. I don't consider the splitting of the Gimp folder ($GIMP2_DIRECTORY) into the three different locations for preferences, cache and application data essential. The compact solution is certainly preferable andeasier to handle for the user.
    It just seemed logical as first attempt to map the XDG spec to OS X guidelines though I have to admit I didn't read Apple's guidelines in detail (e.g. <http://developer.apple.com/mac/library/documentation/MacOSX/Conceptual/BPFileSystem/Articles/WhereToPutFiles.html>). My proposal was based on observing the use of the '~/Library' folder by other applications and interpreting the existing (sub-)directory structure as used by Apple's software.

    About the 'XDG_CONFIG_DIRS' - at the moment I just don't know if it could have any unintended consequences to jail it inside the gimp app structure as well. On my rather vanilla OS X 10.5.8 '/etc/xdg' doesn't exist, and the one in my MacPorts tree looks rather empty ;-) ('autostart' for gnome-keyring-daemon is the only content, never used).

    7) If all GTK+ components built with the patched glib2 are using GIMP2_DIRECTORY as default location for user files, will the Quicklook plugin inherit the GIMP2_DIRECTORY as well?

    With Gimp-2.6.7-p3 it still writes to '~/.gimp-2.6' when I preview an XCF file in the finder. Adding the same environment variable for GIMP2_DIRECTORY to 'Contents/Library/QuickLook/xcf_quicklook.qlgenerator/Contents/Resources/link_launch.sh' fixes this in my Leopard Gimp-2.6.7-p3 installation.

    ~suv

     
  • ~suv

    ~suv - 2009-11-30

    p.s. about migrating the GtkFileChooser settings file in '~/.config/gtk-2.0/':
    *blush* I confused the settings with the list of recently opened files in '~/.recently-used.xbel' which would stay in the same location ($HOME) as far as I understand (it's not in one of the XDG_{DATA|CONFIG|CACHE}_HOME locations). Same goes for the bookmarks that can be added in the 'Places' list of the GtkFileChooser dialog, stored in '~/.gtk-bookmarks', and the '~/.thumbnails' directory.

    Both bookmark files and the thumbnails are shared with other GTK+ applications that use the GtkFileChooser dialog (or widget?) as well.

    i.e. I guess to move the dotfiles that are created directly in $HOME or duplicate their location in GIMP2_DIRECTORY there would be further patches needed. OTOH these files are not directly related to GIMP and shared with other apps - maybe they better stay where they are. ;-)

     
  • Simone Karin Lehmann

    I've used grep on the sources and found another one: '.gtk-custom-papers'

    I've just patched the sources in the current release of 2.6.8p1 SL and 2.6.8 Leopard. I've put some of them into XDG_CACHE_HOME as they are non-essential data, which could easily be rebuild by default.

    So now, the files aree stored in these locations

    XDG_CACHE_HOME, this defaults to GIMP2_DIRECTORY/cache:

    'thumbnails', 'gtk-bookmarks', 'recently-used.xbel' 'gegl-0.0/cache'

    XDG_CONFIG_HOME/gtk-2.0, this defaults to GIMP2_DIRECTORY/gtk-2.0:

    'gtk-custom-papers', 'gtkfilechooser.ini'

    XDG_DATA_HOME, this defaults to GIMP2_DIRECTORY:

    'gegl-0.0/plug-ins'

    As you see, I've moved recently-used.xbel, thumbnails and gtk-bookmarks in GIMP2_DIRECTORY too. Although they are shared with other gtk apps, the data in them is mostly related to GIMP and IMO there won't be much use to see bookmarks from e.g. Wireshark in GIMP. IMO, the same applies to recently-used and thumbnails too.

    What will be more difficult to decide, is how to handle the upgrade to the new files locations. In 2.6.8 for SL I've already moved some files into GIMP2_DIREVTORY without touching or copying the dotted files. :-( So AFAICS, there's now no easy way how to test, if the dot files have to be copied (and will overwrite recently created files by 2.6.8 SL) or not. And I don't know any way to test, if these files are only used by GIMP (and so they could be simply moved to their new location) or are used by some other user installed software. This may even apply to the './gimp-2.6' directory. This is used by the MacPorts version of GIMP and there could be some user installed plugins, brushes, scripts or other configuration in it. IMO it's better to leave them untouched for now and maybe write some instructions for advanced users about this issue, so that the user can decide wether to delete them or not.

    BTW, I fixed the QuickLook plugin too. It doesn't use .gimp-2.6 any longer...

     
  • ~suv

    ~suv - 2010-01-06

    > As you see, I've moved recently-used.xbel, thumbnails and gtk-bookmarks in
    > GIMP2_DIRECTORY too. Although they are shared with other gtk apps, the data
    > in them is mostly related to GIMP and IMO there won't be much use to see
    > bookmarks from e.g. Wireshark in GIMP. IMO, the same applies to
    > recently-used and thumbnails too.

    While downloading the new build for Leopard (big thank you for your efforts!) allow me a quick comment: there is at least one other graphics application that has a lot in common with Gimp (opens the same file types, often connected workflows...) and personally I appreciated that they share the same bookmarks ;)

    'Recent Files' are stored by both applications in 'recently-used.xbel' even if the file entries are assigned to the one that was used to open it - this is a plea to not move (but only copy) that file to a new location without prior warning (my workflow - admitted mainly bug triage for Inkscape - heavily depends on that list being available).

    > how to handle the upgrade to the new files locations

    I tend to agree to:

    > IMO it's better to leave them untouched for now and maybe write some
    > instructions for advanced users about this issue

    but will add further comments after testing 2.6.8. Thanks again for providing the new builds!

    ~suv

     
  • Simone Karin Lehmann

    > and personally I appreciated that they share
    > the same bookmarks ;)

    that would be one of the instructions for an advanced user :-) You can achieve this by first deleting the file '~/Library/Application Support/Gimp/cache/gtk-bookmarks', then place a symbolic link in that directory which points to the gtk-bookmarks in you HOME. Just open Terminal.app and type these commands:

    cd "Library/Application Support/Gimp/cache"

    ln -s ~/.gtk-bookmarks gtk-bookmarks

    > this is a plea to not move (but only copy) that file to a new location

    I haven't done either. '~/.recently-used.xbel' is still there and won't be deleted. so the one in '~/Library/Application Support/Gimp/cache" will be created with an empty content. Now I see, that you're right, it would have been better to copy it to the new location. Sorry. But now, because 2.6.8 is out and does create a new file, I can't release a 2.6.8p1 which will copy the old version to the new location, because that may override any new contents. :-(

    Of course, an advanced user can decide if it's worth to copy the old file (using Terminal.app) to the new location, or let GIMP create a new list of recently used files and if he can savely delete the old one ;-)

     
  • ~suv

    ~suv - 2010-01-06

    > But now, because 2.6.8 is out and does create a
    > new file, I can't release a 2.6.8p1 which will
    > copy the old version to the new location, because
    > that may override any new contents.

    That's ok (for me, I find my way around, no issue) - and most Gimp users won't notice it. Just those Inkscapers that are likely to have both apps installed will notice (if at all ;-) and maybe some die-hard Dia users... (but those know to handle the dotfiles and command line too ;-).

    ~suv

     
  • ~suv

    ~suv - 2010-01-06

    Confirmed with GIMP-2.6.8 Leopard:
    1) these files in $HOME are no longer used:
    ~/.gtk-bookmarks
    ~/.recently-used.xbel

    2) these directories are no longer used
    ~/.config/gtk-2.0/
    ~/.gimp-2.6/
    ~/.local/share/Library/Application\ Support/Gimp/gegl/
    ~/.thumbnails/

    The workaround to use symbolic links to the shared dotfiles in $HOME works ok for '.gtk-bookmarks' and '.thumbnails', but fails for '.recently-used.xbel' and '.config/gtk-2.0/gtkfilechooser.ini': the linked file is read on start-up but on quit GIMP replaces the link with a copy of the file itself.

    I have not yet come across a 'gtk-custom-papers' file.

    ~suv

     
  • Simone Karin Lehmann

    • status: open --> closed-fixed
     
  • Simone Karin Lehmann

    closing this bug (comments still allowed)

    What still needs to be done, is to write some good instructions for advanced users on how to handle the various things mentioned below...

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks