Re: [Gimp-developer] XDG support and better Windows configuration path



On Thu, 2012-10-11 at 13:21 +0900, Jehan Pagès wrote:
> Hi,
> 
> On Thu, Oct 11, 2012 at 10:12 AM, Partha Bagchi <partha1b gmail com> wrote:
> > On Wed, Oct 10, 2012 at 6:12 PM, Michael Natterer <mitch gimp org> wrote:
> >> Hi all,
> >>
> >> Since we are about to change things here, let's do
> >> it right and consistent across platforms this time.
> >>
> >> I suggest:
> >>
> >> OSX: NSApplicationSupportDirectory/GIMP/GIMP_APP_VERSION
> >> WIN: APPDATA/GIMP/GIMP_APP_VERSION
> >> XDG: XDG_CONFIG_DIR/GIMP/GIMP_APP_VERSION
> >>
> >> which means for master:
> >>
> >> OSX: ~/Library/Application Support/GIMP/2.9
> >> WIN: (whatever windows folder i have no clue about)\GIMP\2.9
> >> XDG: ~/.config/GIMP/2.9
> >>
> >> I know the part before "GIMP/2.9" should be handled
> >> by g_get_user_config_dir(), but until it does, let's
> >> do the right thing anyway.
> >>
> >> Comments?
> >>
> >> --mitch
> >>
> >>
> >> _______________________________________________
> >> gimp-developer-list mailing list
> >> gimp-developer-list gnome org
> >> https://mail.gnome.org/mailman/listinfo/gimp-developer-list
> >
> > Yes, I think this will break a whole lot of folks who have gotten into
> > the "bad" habit already with c:/Users/$Username/.gimp-x.x while OSX
> > just went from .gimp-x.x to ~/Library/Application Support/gimp-x.x to
> > ~/Library/GIMP/x.x back to ~/Library/Application Support/gimp-x.x.
> 
> No we have a migration system (it was already in place, I simply
> updated it to now take the current naming into account) which happens
> when you start the GIMP in some version for the first time.
> Basically when 2.10 will go out with the new path, and see there is no
> ~/.config/GIMP/2.10, it will search for ~/.gimp-2.8, then ~/.gimp-2.6,
> etc. And it will migrate if it finds one.
> Only people who compile with --with-gimpdir option different from one
> time to another (but if they always used the same, or the defaults, no
> problem), and maybe people who use the environment variable (because
> they never let GIMP migrate their options properly), can have a
> problem. Otherwise no breakage.
> In other words, the problem may happen for those who use custom
> folders rather than the one using default settings.
> 
> > Can't we simply make this a user configuration as it used to be before
> > where one could select the user directory?
> 
> Setting of the configuration folder's name at compile time
> (--with-gimpdir) stays, but it is now relative to the user
> configuration directory, not the home. So you can call your folder
> BLABLA/2.10 instead of GIMP/2.10, if you really wish so.
> Actually by the new system that Michael proposes, we will even fix a
> potential migration breakage where people were choosing a folder name
> without the version in it. Hence migration of configuration could
> break (in case something had to change, but GIMP can't know it has to
> migrate).
> 
> The configuration by environment variable ($GIMP2_DIRECTORY) stays as
> well and is still the priority if set. Also it is still relative to
> $HOME directory if relative, as it used to be (for the exact reason
> that I don't want to break existing configuration).
> 
> That leads me to wonder: what do we want to do if the variable is set:
> 1) We save directly under this path. Hence we never know if a version
> bump (or downgrade) occurred (hence there can be problems at every
> change of version for this user's configuration if ever something a
> little more than copy-paste needed to happen).
> 2) We now make a subdirectory with the version. Hence $GIMP2_DIRECTORY/x.x/.
> 
> I would think that we could go with 2). That's a little more work to
> detect the situation but that's nicer to the users. What do you think?
> Of course, if you don't want, that's just less work for me, so I am
> ok. :p

We can't do that, gimp_directory() returns the folder where
stuff is stored, and i should stay that way.

> > Of course, if the above will be the rule, at least publicize it in advance?
> 
> I can't answer for this, but I guess there could be a news, of course.
> But as I said, that should be transparent to most users. Hence a
> simple item in the release note should be ok. But a news is always
> nice because a lot of people waited for XDG support. :-)
> 
> Jehan




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]