GNOME Bugzilla – Bug 332620
Profile migration doesn't convert paths in gimprc
Last modified: 2008-01-15 14:05:55 UTC
Please describe the problem: Using a profile migration from gimp 2.2 to gimp 2.3 doesn't convert script-fu-path for example. Steps to reproduce: 1. Use Gimp 2.2 and change/update script-fu paths in preferences dialog 2. Close it 3. Start a fresh Gimp 2.3 (without ~/gimp-2.3/) and choose "migrate profile from 2.2) Actual results: Your new Gimp 2.3 will use Gimp 2.2 scripts Expected results: Gimp 2.3 should use its own installed scripts Does this happen every time? Yes; it should even happen for other Gimp ressources (plug-in, brushes,...) Other information: May-be the problem is that paths are written in gimprc using absolute paths and not using ${gimp_dir} and ${gimp_data_dir} variables. In this case, the problem is really in 2.2.x release.
The migration cannot properly handle the case where you explicitely set a path. This is a minor problem though because users who have changed their paths explicitely obviously know what they are doing and are able to change the path after the migration.
I think my test case is unclear; that's what I really did: 1) start Gimp 2.2 2) change the order of the two default paths for scripts 3) quit Gimp 2.2 4) Start a fresh Gimp 2.3 (without ~/gimp-2.3/) and choose "migrate profile from 2.2) 5) wonder a little why your scripts for gimp-2.3 are incorrect. So I didn't really set new paths. That's the real problem. Because I don't add paths into Preferences.
My argument still applies. You fiddled with the paths, thus you know what you are doing. Of course this could be improved, but it isn't trivial to do that and thus probably the changes are simply not worth the effort.
This also happens with 2.0->2.2 migrations, and not only in the case that users fiddled with the paths. This is in my .gimp-2.3/gimprc: (temp-path "/home/ari/.gimp-2.2/tmp") (brush-path-writable "/home/ari/.gimp-2.2/brushes:/usr/share/gimp/2.0/brushes")(pattern-path-writable "/home/ari/.gimp-2.2/patterns:/usr/share/gimp/2.0/patterns") (palette-path-writable "/home/ari/.gimp-2.2/palettes:/usr/share/gimp/2.0/palettes") (gradient-path-writable "/home/ari/.gimp-2.2/gradients:/usr/share/gimp/2.0/gradients")
As a followup to my previous comment, I might have been wrong about fiddling with my paths. But if I did, I still set them back to the defaults, which means they should certainly be migrated properly. Therefore, if I manually set a path to the default value, shouldn't it just be removed from my gimprc?
You did set it to the expanded default value, which is not identical to the the default value. That's why it's not automatically removed. Sure, this could be improved. It's just a question of whether it's worth the effort.
Created attachment 75576 [details] [review] Patch fixing the bug I don't think we should migrate paths at all. A user who adds an additional directory for brushes doesn't expect that this affects all directories in his brush path even across a migration. Having to re-add custom folders is IMHO not too much asked. Attached patch fixes the bug, but I would like a comment from Sven before comitting.
Looks fine, even though I would still like to see the issue being addressed in GimpConfig.
When you commit the patch, please add a comment that explains why this code has been added. It's probably not obvious why it is needed...
My plan was to move it to gimp_rc_migrate(), I don't see any other GimpConfig place where such special code would make sense.
Fixed in CVS: 2006-10-29 Michael Natterer <mitch@gimp.org> * app/config/gimprc.[ch]: added gimp_rc_migrate() which resets all GimpParamConfigPath properties to default values. * app/core/gimp-user-install.c (user_install_migrate_files): use the function. Fixes bug #332620.
Resetting path to defaults OK with 2.3.16