I'm a Product Manager by day...

From my perspective, changing the location of the preference files on Unix-like platforms doesn't provide significant value either to the end user or to making the code more accessible to prospective developers.

I'd much rather see development time go into things that provide more tangible benefit.



On 01/16/2011 09:12 AM, Geert Janssens wrote:
Thanks for your feedback.

On Sunday 16 January 2011, Jeff Kletsky wrote:
In my opinion, adopting a "standard" that

* goes counter to long-established practice

 From what I've read is serves a different target audience. The XDG base
specification was created to cater for a new breed of users: ordinary desktop
users that don't know/care about config files or user specific application
data. As such the intended target applications for this spec are desktop
applications. I think GnuCash falls into that category. The long-established
practice still holds as far as I'm concerned for anything more power user
(things like mutt, lynx, vi, emacs,...).

* isn't widely accepted

This is mostly a chicken-and-egg problem. Not adopting a new standard because
it's not widely accepted will never get it widely accepted.

will cause more problems than it is worth.


There is a significant documentation change cost for GNUCash.

6 lines in the Help Manual and Concepts Guide combined
7 comment lines in the code
A number of entries in the wiki
What did I miss ?

There is a significant coding/test cost (either auto-upgrade, or
checking two locations, and possibly having both present)

There are examples that can be reused. Rhythmbox has implemented a silent
migration, Comix does a migration after asking the user.
There is a significant support cost ("Where are the config files? They
aren't where everything else is.")

Again the chicken and egg issue. As more GUI apps start using the XDG
standard, the config files will be in the expected location.
As far as I can tell, there is nothing that I use on FreeBSD that uses
~/.local/share (they are very adamant about non-base applications
installing system-wide data into /usr/local/etc, not letting everything
throw into crap into /etc) and on Ubuntu, only webkit's icons and
gvfs-metadata are found there.

As far as I can see, you are mixing things up here. The choice between /etc or
/usr/local/etc has nothing to do with the user. Both are for system wide
preferences. Moving from $HOME/.<appname>  to .local/share or .config (thanks
John for pointing that out) is for user specific data generated by the
application.

I see more and more applications that start to adhere to this specification.
There is a proposed GnomeGoal as well, though it's not approved yet.
Considering Gnome is part of the Freedesktop platform (as is KDE and Qt) I
expect them to come through with the spec at some point.

But I also see this spec stirs up a lot of discussion so probably it's best to
let the dust settle before we make our final decision. There's no hurry. I
didn't intend to make these changes before 2.6 anyway.

On Mac, things generally go into ~/Library/Application Support (though I
haven't read developer docs for OS X in ages).

I would expect g_get_user_config_dir or g_get_user_data_dir to return that
path by default, but I'm afraid I don't know how glib on OS X works.

Geert

Jeff

On 01/16/2011 07:19 AM, Geert Janssens wrote:
Historically, GnuCash has always stored its user specific application
data in ~/.gnucash based on old linux (unix ?) conventions.

This didn't work really well on Mac OS X/Quartz, so John has overridden
this path on OS X to make more sense there.

Now there's a bugreport that indicates this isn't the best place on
Windows either [1].

I could override the path on Windows as well and be done with it, but in
my investigation I found that even on linux ~/.<appname>   is no longer
the recommended place to store such information.

According to the XDG Base Directory Specification [2] the preferred
location is ~/.local/share/<appname>.

The nice thing is, glib has a convenience function g_get_user_config_dir,
which by default returns ~/.local/share on linux and the equivalent and
proper ~\Application Data (Windows XP) or ~\AppData\Roaming (Windows
Vista/7).

I don't know what this routine returns on OS X, but I would expect it to
return the proper location for user specific application data there as
well. If not that should be reported as a bug againse glib on OS X.

In this light I would like to update the GnuCash code to make use of the
g_get_user_data_dir function on all platforms and rename the directory
from .gnucash to gnucash. That would give a better experience on all
platforms IMO. This is what the directories would become:
- Linux: ~/.local/share/gnucash
- Windows XP: c:\Documents and Settings\<user>\Application Data\gnucash
- Windows Vista/7: c:\Documents and
Settings\<user>\AppData\Roaming\gnucash - OS X: ?

I would obviously have to provide some conversion code as well, that
would copy the old .gnucash contents to .local/share/gnucash to
guarantee continuity for the users.

I also think this change may be better for 2.5/2.6 than 2.4.1.

Does anyone have any objections to this ?

Geert

[1] see https://bugzilla.gnome.org/show_bug.cgi?id=503722
[2] see
http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html
_______________________________________________
gnucash-devel mailing list
[email protected]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

_______________________________________________
gnucash-devel mailing list
[email protected]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Reply via email to