Moving .gnucash and friends from $HOME to XDG_DATA_HOME (and impact on other applications like KMyMoney)

John Ralls jralls at ceridwen.fremont.ca.us
Fri Aug 25 10:22:27 EDT 2017


> On Aug 24, 2017, at 5:19 AM, Geert Janssens <geert.gnucash at kobaltwit.be <mailto:geert.gnucash at kobaltwit.be>> wrote:
> 
> On donderdag 24 augustus 2017 12:11:48 CEST John Ralls wrote:
>>> On Aug 24, 2017, at 8:57 AM, Geert Janssens <geert.gnucash at kobaltwit.be <mailto:geert.gnucash at kobaltwit.be>>
>>> wrote:> 
>>> On woensdag 23 augustus 2017 23:21:23 CEST John Ralls wrote:
>>>> A new default should apply only to new installations and should be
>>>> overridden by $GNC_DOT_DIR and $AQBANKING_HOME; we should continue to
>>>> include ~/.gnucash and ~/.aqbanking in the default search and use the
>>>> first
>>>> instance of the config file we find.
>>> 
>>> While that is conservative and safe, it would also require us to support
>>> the outdated directories forever and by extension make our code more
>>> complicated for that same period. So I'm not in favor of this strategy.
>>> 
>>> And I'm not the only one. I have come across several applications in my
>>> long use of linux that have chosen not to do that either. Two come to
>>> mind immediately: libreoffice has changed user data directories with
>>> every major release for as long as I have used it. It has always copied
>>> the old one and didn't even bother telling the user about this. KMail did
>>> a similar migration twice, and informed the me about it on each occasion.
>>> 
>>> So I think to point of view to take here is gnucash 2.8 is a new
>>> application that knows how to import settings from an older application
>>> (which happens to be gnucash 2.6 or older). At some point in the future
>>> nobody will still be using the old application at which point the user
>>> can decide to drop the configuration that old app used (I think nobody
>>> does that in real life though).
>>> 
>>> I agree an override option should exist indeed. Not in the least because
>>> you're using it on OS X :)
>>> 
>>> On the other hand I think GNC_DOT_DIR is tied way too much to the old
>>> directory format and I prefer to change it to GNC_DATA_HOME (as GNC_HOME
>>> is
>>> already in use to point at the base installation directory).
>>> 
>>>> The XDG environment variables are appropriate in the Gnome and KDE
>>>> desktop
>>>> environments on Linux and pretty much nowhere else. Perhaps the best
>>>> approach would be to set reasonable defaults per OS and allow them to be
>>>> overridden with a CMake variable and configure argument.
>>> 
>>> The per OS defaults are a good suggestion. On linux and compatible that is
>>> XDG_DATA_HOME/Gnucash, on Windows CSIDL_APPDATA\Gnucash. I'm only missing
>>> this on OS X. Is there a function in the Quarz framework that would
>>> return ~/ Library/Application Support/ so a similar default path can be
>>> created ? I'd want the defaults to be such that no environment variable
>>> should be set to get them.
>>> 
>>> About the override in Cmake or configure, I doubt that makes much sense.
>>> These directories have no use during build, only at runtime*. And at
>>> runtime they can be overridden by GNC_DATA_HOME and AQBANKING_HOME.
>>> 
>>> Geert
>>> 
>>> * Strictly speaking I should say "should have no use during build".
>>> Unfortunately compiling the guile sources will cause the user_data_dir
>>> functions to be run. It's guile's way of evaluating whether dynamically
>>> loaded modules won't call other guile sources that need to be compiled :(
>>> I'm still evaluating whether this is bad for my new code or not.
>> 
>> Re backwards compat, OK, I guess. Moving the default for GnuCash isn't
>> really the issue, it's AQBanking. Unless we convince Martin to go along
>> we're either going to have a hack like linking or to support ~/.aqbanking
>> forever.
>> 
> For AQBanking we may have to consider this per platform. For OS X/Quarz and 
> Windows we bundle AQBanking. So on those platforms at least  we can consider 
> it private to gnucash and don't worry about other applications wanting to use 
> it. We'd even don't want that. So it's also reasonable to consider its 
> configuration private enough to gnucash to decide for our own where we want to 
> store it.
> 
> On linux and several other package based platforms aqbanking is normally a 
> system library. So perhaps on those platforms we should leave things as they 
> are or keep a fallback. At some point I'll probably take it up with Martin/
> Christian as well to check whether they are interested in implementing the XDG 
> specification on free desktop abiding platforms.
> 
> That's not in the 2.8 time frame though.
> 
>> Re GNC_DOT_DIR on Mac: But if GnuCash sets the default data directory to
>> ~/Library/Application Support then I won't need the environment variable
>> override.
>> 
> Indeed. I didn't mention that separately because my previous mail already had 
> too many words :)
> 
>> The reason for providing a CMake/configure override is because people build
>> GnuCash on platforms besides the 3 we overtly support including the various
>> BSDs, True64, and Solaris. There was even somebody running it on OpenVMS a
>> few years ago, but we haven't heard from him in a long time. I think some
>> of the BSDs distribute GnuCash  binaries, and it would be courteous to
>> provide those packagers with a convenient way to set up GnuCash for
>> whatever their defaults are.
>> 
> The end value is dependent of the username or home directory of the end user 
> running it.
> 
> I'm not sure how this can be elegantly set at build time in a way that it's 
> generic enough to work for all users. Unless you can pass (pseudo)variables 
> that will only be parsed at run time. I imagine in such environments the 
> proper thing to do is to write additional lines to the environment file (/etc/
> gnucash/environment or something similar).
> Setting GNC_DATA_HOME and/or AQBANKING_HOME in there to something based on 
> {home} (environment file notation) will then work for all users. Most 
> packaging systems or installers have post-install hooks that can do this. Do 
> we still have to provide another way already at build time ?
> 
>> We'll also need a fallback on Linux if XDG_DATA_HOME isn't defined or
>> GnuCash will barf because it can't create /gnucash.
>> 
> Absolutely. For now I made it easy on myself. I'm still using the glib routine 
> g_get_user_data_dir() which handles this adequately. If I drop that function 
> (which would not be unreasonable), I'd have to do the fallback myself.
> 
>> The Cocoa key for ~/Library/Application Support is
>> NSFileManager::NSApplicationSupportDirectory. There's example code at
>> https://developer.apple.com/library/content/documentation/FileManagement/Co <https://developer.apple.com/library/content/documentation/FileManagement/Co>
>> nceptual/FileSystemProgrammingGuide/ManagingFIlesandDirectories/ManagingFIle
>> sandDirectories.html
>> <https://developer.apple.com/library/content/documentation/FileManagement/C <https://developer.apple.com/library/content/documentation/FileManagement/C>
>> onceptual/FileSystemProgrammingGuide/ManagingFIlesandDirectories/ManagingFIl
>> esandDirectories.html>.
> 
> Thanks, I'll see if I can cook up something based on that. You may have to 
> correct this as my Objective C experience is about 0 :)

For the CMake/configure option my thought is to have something like --set-default-user-data-dir which would take a single path string to be appended to $HOME and if defined would remove the XDG-checking code, but you're right that packagers can also use a post-install hook to set the environment variables either in  /etc/gnucash/environment, /etc/bash_profile, or in the desktop file. On the other hand you could also just go that route directly and stuff the appropriate values into gnucash/environment at build time and leave the runtime code alone.

This code is for gnucash rather than libgnucash, right? In that case there's no point in removing glib until we're also ready to remove gtk and we'll just replace the cross-platform utility functions like that with whatever functions the replacement framework provides. I wouldn't waste time on hand-rolling replacements unless there's a good reason to.

Regards,
John Ralls



More information about the gnucash-devel mailing list