gimp_abs_paths.txt

* Now talking on #gimp
* Topic for #gimp is: Don't ask to ask, just ask. || GIMP 2.8.18 is available || Please register with NickServ
* Topic for #gimp set by Wilber at Thu Jul 14 03:12:04 2016

<probono> hi all, mitch: is there a way to stop gimp from hardcoding the absolute patch to ${gimp_data_dir} into the settings files saved in $HOME?
<probono> (background of the question: https://github.com/probonopd/AppImages/issues/80)
* meb has quit (Ping timeout: 183 seconds)
<probono> in other words, how do I stop gimp from "querying new plugins" every time the location of  ${gimp_data_dir} changes?
<schumaml> why does it change?
<probono> because i am executing gimp from a different temporary location each time it is launched
<probono> this is how AppImage works
<schumaml> somehow each of those "easy" packging approaches fails short of my expectations
<probono> schumaml, in which respect?
<probono> AppImage is extremely easy: it is just a self-mounting ISO that contains the app and its dependencies. when you execute it, the ISO is mounted and the app is executed. simple.
<schumaml> yeah, but apparently by an ever-changing path
<probono> i can't see why this is a bad thing, in contrast, how else would you be able to run multiple versions in parallel..
<nomis> probono: are there environment variables where the app could determine its root folder?
<probono> nomis, yes. $APPDIR is where usr/ is in
<nomis> ...and can it *write* to its ISO?
<probono> no, why should it?
<schumaml> so the actual issue here seems to be that pluginrc is recreated
<schumaml> because this includes the path to the plug-in and their checksums, to discover changed plug-ins
<nomis> also the modification date of the plugin binaries.
<nomis> I don't think it is an actual checksum
<schumaml> I don't really see how using ${gimp_data_dir} would change anything there, though
<probono> couldn't ${gimp_data_dir} be used instead of abs paths?
<probono> ${gimp_data_dir} never changes whereas the abs paths do
<schumaml> why would ${gimp_data_dir} not be /tmp/... in this case?
<probono> i would imagine that when gimp loads the .xml, then it replaces ${gimp_data_dir} with whatever this directory is at the moment
<nomis> probono: the problem is, that there may be plugins outside of ${gimp_data_dir}
<probono> so how does gimp determine when to recreate these files in .config?
<schumaml> probono: what xml, btw?
* electricprism (quassel@2601:645:100:249d:1589:a086:dfcb:d765) has joined #gimp
<probono> /home/me/.config/GIMP/2.9/tags.xml for example
<probono> has lots of hardcoded <resource identifier="/tmp/.mount_cA2b4A/usr/share/ ...
<schumaml> this is about pluginrc
<nomis> probono: AFAIK it iterates over the entries in the pluginrc and stat()s the paths specified there.
<probono> i am essentially talking about all of $HOME/.config/GIMP
<nomis> schumaml: the point is, that pluginrc could employ a similiar mechanism as tags.xml
<probono> which i want to get free of absolute paths
<probono> if i read this correctly, this was a similar intention here: https://mail.gnome.org/archives/commits-list/2009-November/msg01994.html
<Wilber> Title: [gimp] Use ${gimp_dir} and ${gimp_data_dir} in tags.xml (at mail.gnome.org)
<nomis> probono: I take it that the appimage-mechanism cares about setting the proper values into $gimp_data_dir?
<probono> it could do that, yes, if gimp itself doesn't do that
<probono> well if it is an ENV
<nomis> hm, I am actually unsure where that comes from.
<schumaml> I'm not sure if using ${gimp_data_dir} in pluginrc would change anything at all
<ender> which IIRC was added specifically to support portable GIMP on Windows?
<schumaml> relevant code should be in https://git.gnome.org/browse/gimp/tree/app/plug-in/plug-in-rc.c
<Wilber> Title: gimp - GNU Image Manipulation Program (at git.gnome.org)
* skweek has quit (Ping timeout: 186 seconds)
<probono> ender, it is mentioned in m4macros/gimp-2.0.m4 and libgimpconfig/gimpconfig-path.c and app/config/gimprc.c
<probono> but seems undocumented
<ender> possibly
<ender> IIRC, the way it works is to let GIMP create pluginrc once, then replace the absolute path with ${gimp_plugin_dir} - as long as the plugins don't change, it'll stay like that
<schumaml> hm, the code might even handle variable expansion there already
<schumaml> probono: does it work if you modify pluginrc manually?
<probono> let me try
<probono> find /home/me/.config/ -type f -exec sed -i -e 's|/tmp/.mount_iXW3zE/usr/lib/gimp/2.0/|${gimp_plugin_dir}/|g' {} \;
<probono> still does "Querying new Plug-ins"
<nomis> probono: I doubt that the code for the pluginrc actually does the substitution.
<nomis> something very similiar to the 2009 patch is needed in app/plug-in/plug-in-rc.c:plug_in_rc_write()
<schumaml> I wonder what files it was looking for during this attempt
<nomis> and I am not sure if the gimp_config_path_expand() in plug_in_def_deserialize() does the variable substitution, it sounds like it should.
<schumaml> that is what I was hoping, but it was mostly a guess based on the "expand" of the procedure name
<nomis> same for me  :)
<probono> do you think a patch for app/plug-in/plug-in-rc.c:plug_in_rc_write() would be considered?
<nomis> probono: yeah.
<nomis> gimp_config_path_expand() definitely does the expansion.
<probono> given that this was a 26 lines patch, could you imagine to do it?
<schumaml> http://developer.gimp.org/api/2.0/libgimpconfig/libgimpconfig-GimpConfig-path.html#gimp-config-path-expand
<Wilber> Title: GimpConfig-path (at developer.gimp.org)
<schumaml> so how do I tell what files gimp is accessing with a plug-inrc changed like this on a linux platform?
<nomis> probono: the problem is, that I can't properly check if it works for you.
* aday has quit (Quit: aday)
<nomis> schumaml: if you start up gimp verbosely it might print out relevant information.
<probono> sure: install to $PREFIX e.g., "/foo/" then move this to a different location e.g., "/bar/" and see if it re-scans the plugins
<probono> if it doesn't then it works as intended :-)
<schumaml> no really, that would be trying to guess from symptoms
<nomis> probono: well, in my list of interesting problems this is on a pretty low priority  :)
<probono> can i get it higher up the list if i promise a working AppImage in return? :-)
<probono> this is how we create the AppImage: https://gist.github.com/aferrero2707/2da99aae425eca8c8afb61b3fb5532f9
<schumaml> I'm pretty sure that the variable is exspanded, but the resulting path is recognized as different - i.e. the original file isn't found - and so a new query is done
<probono> argh
probono> so how would you go about it? just let the appimage be mounted at the same mount point every time and forget about it?
<schumaml> so I guess we might have to resort to checksums, like it is done for resources
<schumaml> simple modification dates won't cut it for randomly changing locations
<nomis> probono: how does the file modification date for appimages behave?
* jluc has quit (Quit: Leaving)
<nomis> is it guaranteed to stay the same across mounts?
<probono> yes
<schumaml> then again, calculating checksums is probably even more heavy ;)
<probono> working with many different apps i actually never saw this pattern where a config file hardcodes the path to the app
<probono> because the app usually "knows where it is" without needing the help of config files
schumaml> what I don't like about that appimage is the additional plug-ins
<probono> can't they just go into $HOME?
<schumaml> probono: that is less of a config file and more of a cache
<probono> yes i see
<schumaml> to make the start of gimp faster, by making a query for the plug-in procedures unnecessary if they files have not changed
<schumaml> as you can see, gimp finds the plug-ins just fine, but they are considered to be potentiually changed
<probono> yes and this is why people say "gimp is much faster when installed, compared to the appimage"
<probono> crude idea, would a constant symlink to the mountpoint do the trick?
<schumaml> that and probably because you disable all of mmx, ssee, sse2, sse4, ... in babl
* gez has quit (Connection reset by peer)
<probono> if gimp was always launched via the symlink?
<probono> probably not... because the symlink gets resolved early on
<schumaml> hm, and you pull from github
<probono> is that a bad idea?
<schumaml> we don't control those repositories, so this is a bit risky
<schumaml> they should be mirrors, but we can't guarantee that
<probono> ok, should be easy enough to change
<schumaml> the solution to the pluginrc issue is probably a paradigm shift - instead of checking that a file at a known and fixed location still has the same timestamp, we'd have to check if a file at an arbitrary random location happens to have the same name and timestamp as a file at a previsouly different location
<probono> ...with "arbitrary random location" = one of the defined variables
<schumaml> yeah, but the value of said variable changes
<probono> yes
<schumaml> just to make sure, the pluginrc file you had modified got rewritten by gimp with absolute paths?
<probono> yes
<probono> in case you want to give it a try, here is the thread about the AppImage https://mail.gnome.org/archives/gimp-developer-list/2016-August/msg00006.html and here it is for download https://pixls.us/files/gimp-2.9.5-20160830.glibc2.15-x86_64.AppImage
<Wilber> Title: [Gimp-developer] GIMP 2.9.x AppImage for testing (at mail.gnome.org)
<nomis> I feel stupid. I don't find the place where the mtime is checked.
<schumaml> probono: I don't own any system that could run this :)
<probono> no x86_64 linux box?
<schumaml> no
<nomis> ah.
<nomis> the logic is inverted to what I assumed.
<nomis> gimp_plug_in_manager_search_directory iterates over the files in a directory and then hands the file + mtime to gimp_plug_in_manager_add_from_file, which in turn tries to find an entry in the known plugin-entries.
* Kevin has quit (Ping timeout: 182 seconds)
<schumaml> ah
<nomis> (which probably fails with the ${...} stuff}
===
<probono> sorry I had to leave yesterday night, was a conclusion reached on the hardcoding of paths to ${gimp_plugin_dir}?
<probono> nomis ^^^
<nomis> not conclusively.
<nomis> probono: I have a better understanding of the code in question. It is a bit convoluted and it is not obvious where to replace what.
<probono> i see nomis
<probono> thanks for looking at it
<nomis> My gut feeling is, that it needs some hash tables. Right now it compares every found file against every known plugin from pluginrc. Not that I am very much concerned about run time but it just feels... wasteful.
===
<probono> mitch, it gets stored as a hardcoded absolute path in $HOME/.config
<probono> the concrete use case here being AppImage
<mitch> where exactly does it get stored?
<mitch> plurinrc?
<probono> which contains gimp inside a disk image, which gets mounted at runtime at a temp location
<probono> mitch, https://nopaste.me/view/raw/c494d4aa
<probono> so, pluginrc and themerc
<probono> in my use case, /tmp/.mount_m2aPW2/ keeps changing on each gimp launch
<probono> and this causes each gimp launch to be painfully slow
<mitch> ah
<mitch> that's easily fixed
<mitch> give me a minute
<mitch> probono: fixed, pull
<probono> mitch, excellent, thanks a lot
<mitch> better test first ;)
<probono> sure :)
<mitch> all stored paths should be fixable the same way, except perhaps the themerc because that's not parsed by gimp
<mitch> but wait
<mitch> themerc is written on startup anyway
<probono> as long it doesn't do the slooow plugin scanning
<probono> it's fine
<mitch> well there is a problem if the user e.g. configures their brush etc folders
<Wilber> Michael Natterer master * 9f343f2 gimp : app: try to store plug-in paths in terms of ${gimp_plug_in_dir}
<mitch> they will point to the relocatable bundle location once expanded from ${gimp_data_dir}
<mitch> hmm
<mitch> bad
<probono>  ${gimp_data_dir} should be expanded as "late" as possible
<probono> i.e., dynamically depending on where  ${gimp_data_dir} points to at that point in time
<mitch> probono: that does happen, but it never gets substituted back if the user edits the paths in prefs
<mitch> hmm that needs to be done at the exactly right place...
<nomis> for the pluginrc this needs to be done in gimp_plug_in_manager_add_from_rc and gimp_plug_in_manager_add_from_file AFAICT.
<mitch> nomis: already done, pull
<mitch> you were thinking too complicated :)
<nomis> quite possible  :)
<mitch> it just needs to be written to pluginrc correctly
<nomis> erm.
<mortisha> seems google interested in fix webp gimp bugs
<nomis> mitch: when the code iterates over the files to find new plugins, the (real) path/filenames get compared to the entries from the pluginrc. How is just changing the paths written to pluginrc helping there?
<mitch> nomis: because on parsing they go through gimp_config_path_expand(), the ${gimp_foo_dir} must only ever exist on disk
<mitch> mortisha: that's good news, maybe i should push my own fixed asap then
<nomis> ah. Hm. IIRC schumaml yesterday tried a manual replacement in the pluginrc and had reported that it didn't help.
<nomis> anyway, probono will tell us if it doesn't help  :)
<mitch> he replaced it like it is now, or did he happen to replace the literal "/plug-ins" too
<mitch> that's not part of ${gimp_plug_in_dir}
<mortisha> mitch massimino is a goggle webp developer https://bugzilla.gnome.org/show_bug.cgi?id=769960
<Wilber> Title: Bug 769960 animated WebP loader is not properly handling blending and transparency (at bugzilla.gnome.org)
<mitch> mortisha: ah, great
<mitch> nomis: hmm, if people copy their gimpdir to be used as a temp thing, the paths will point to the original gimpdir
<mitch> maybe we should replace that too
<probono> mitch, nomis: can't build it right now but will let you know asap whether it helped
<mitch> i need a function name that's the opposite of gimp_config_path_expand()
<mitch> collapse?
<mitch> come on, one proper native speaker :P
<mitch> expand vs. collapse
<mitch> i'm 99% sure but is there a better word?
<nomis> _symbolify()
<nomis> suddenly collapse becomes quite acceptable  :)
<nomis> _abbreviate()
<mitch> _resubstitute()
<mitch> shiver
<mitch> yes i think collapse :)
<nomis> unexpand()