I've got a bug report on the Debian asunder package saying:
> config for Asunder is spreaded under four different files in home directory.
> Should not that be under ~/.config/asunder ?
and looking at the freedesktop specification at
> $XDG_CONFIG_HOME defines the base directory relative to which user specific
> configuration files should be stored. If $XDG_CONFIG_HOME is either not set
> or empty, a default equal to $HOME/.config should be used.
I have found the glib function g_get_user_config_dir which looks like
a good candidate for this - or to be specific something like
g_get_user_config_dir() + "/asunder/<filename>"
should probably work fine.
(On the debian-machines I have tested, $XDG_CONFIG_HOME, which you use is empty, but g_get_user_config_dir returns ($HOME)/.config )
Would you accept patches for fixing this?
Do you know what 4 files they're talking about? I'm pretty sure it's just one.
I considered fixing this before, but the problem is it would take quite a bit of extra code to make sure that the new version of Asunder first loads the settings from old ~/.asunder before it switches to using the new file.
As far as I can tell there's no benefit whatsoever from using the new file location and I don't want to piss the users off by resetting their settings.
Do you have any suggestions for how to deal with that?
(In reply to Andrew Smith from comment #1)
> Hi Andreas
> Do you know what 4 files they're talking about? I'm pretty sure it's just
I have .asunder, .asunder_album_artist, .asunder_album_genre and .asunder_album_title in my $HOME.
> I considered fixing this before, but the problem is it would take quite a
> bit of extra code to make sure that the new version of Asunder first loads
> the settings from old ~/.asunder before it switches to using the new file.
> As far as I can tell there's no benefit whatsoever from using the new file
> location and I don't want to piss the users off by resetting their settings.
Yeah, surely it would be really bad to simply reset the user settings, there would have to be some kind of migration from the old to the new position, and that means some amount of code, yes...
(In reply to Andreas Rönnquist from comment #2)
> I have .asunder, .asunder_album_artist, .asunder_album_genre and
> .asunder_album_title in my $HOME.
Embarassingly I have no idea where those files are coming from. I wonder if libcddb creates them maybe? Sounds like a stretch but I have no recollection of ever working with these files.
> Yeah, surely it would be really bad to simply reset the user settings, there
> would have to be some kind of migration from the old to the new position,
> and that means some amount of code, yes...
Well, you asked if I would accept patches to deal with it - I certainly would if you wrote that code.
Created attachment 6 [details]
patch to load config from g_get_user_config_dir
I have made this patch, it loads in order from
but always saves to the g_get_config_dir location.
Please try it out - I am thinking if there should be
some dialog or something like that the first time the
config gets moved, but it might not be necessary.
Thanks Andreas, looks very good. I also don't think a dialog is necessary.
Can you please fix a couple of things:
1) Since you're using g_build_filename(), those strings need to be later freed with g_free()
2) There are some tabs in your patch, please replace with spaces.
Created attachment 7 [details]
Updated patch to fix freeing filenames and fixing tabs
Here you go - this should look a bit better.
I've checked it in with minor changes.
I found where the other .asunder* files are created, it's in completion.c
Currently it uses XDG_CACHE_HOME but of course on most systems that's not set to anything just as XDG_CONFIG_HOME is not set to anything. So they end up where they are.
Any chance you could modify completion_filename() to do as get_prefs_save_config_path() does and create ~/.cache/asunder/ before returning ~/.cache/asunder/asunder...?
I can do it if you don't have the time.
Created attachment 8 [details]
Fixes cache file locations
Alright, I have put together this, please take a look at it.
Awesome, thanks! I've checked it in.
Your patches will be in the next release and I'll be adding you to the credits.
*** Bug 52 has been marked as a duplicate of this bug. ***