XDG Base Directory Specification

[blaksaga]

I am wondering if you do or if you plan on supporting
the FreeDesktop.org XDG Base Directory Specification
located here:

 http://standards.freedesktop.org/basedir-spec/latest/

In this specification all linux config files should be
placed in the $XDG_CONFIG_HOME/<app> directory. If the
environment variable $XDG_CONFIG_HOME is not defined it
sould default to ~/.config/<app>.

This is the latest FreeDesktop.org standard and is
being adopted by more and more applications.

[vadz]

I guess we should respect this in wxStandardPaths, although
I hesitate to do this by deault -- people would never find
their config files otherwise. It shouldn't be difficult to
implement, once we understand what exactly we're implementing...

[brot]

It would be great if you could implement the latest FreeDesktop.org standard. Yesterday I filled a bug on the Editra-Project ( http://code.google.com/p/editra/issues/detail?id=346) and so I noticed that this request should be respected by your toolkit.

More and more programs change this to respect the FreeDesktop.org standard, so it should be no problem to save the config-files into ~/.config

[vadz]

The problem is compatibility: if we simply changed wxStandardPaths to always behave in the new way the users of wx programs would silently "lose" their configuration after upgrading which is clearly unacceptable. I see only 2 solutions:

1. Check if ~/.app exists and return it if it does but return ~/.config/app if it does not.
2. Add a UseDotConfig(bool useIt) method which would need to be explicitly called to use the new naming scheme.

I think (2) is better because it's simpler and safer, even if it means that we still wouldn't be following the standard by default.

[stegdiwxw]

It would be nice to fully support the XDG standard for version 3.0, which is the status of this, any news?

[vadz]

Nobody is actively working on this AFAIK. It should be pretty easy to implement (2) suggested above so if anybody wants to contribute a patch implementing it, it would be welcome.

[eheintzmann]

* ping

[Alatar]

+1

[vadz]

The last 2 comments are not useful. We are aware that people are interested in this but clearly not enough to do anything about it. It really is pretty simple to implement and if anybody really wants to have it, please implement the suggestion of the comment:4 and submit a patch with your changes.

[Alatar]

I`m try to implement first variant. GetUserConfigDir now always return XDG_CONFIG_DIR, but wxFileConfig check existence of required files there and, if this is not exists, try to find file in old location. If it missing to, wxFileConfig use XDG-compliant path.

BTW, when I try to use subdir and this dir not exist, wxFileConfig cause error message "Failed to create a temporary file name" on Write. Is this normal? May be we should try silently create config subdirectory before write?

[vadz]

Sorry, I still disagree with this solution. wxFileConfig is not the only code calling GetUserConfigDir(), it can be -- and is -- also used from the code outside wxWidgets and changing it like this would still result in the existing programs not finding their config files any more. We did experiment with adding app/vendor name to the config files/directories by default already and it was a disaster, so we had to revert to the old behaviour and add wxStandardPaths::UseAppInfo() to allow to explicitly switch to the new behaviour. So I really think that the best solution here would be to do the same thing and add a new UseXDGDirectories() method (I called this UseDotConfig() before but it should affect GetUserDatair() too, so I think a more generic name would be better) that would allow to explicitly switch to the new behaviour.

Could you please modify the patch to make it work like this? Of course, wxFileConfig wouldn't need to be modified at all then, so it would actually make the patch simpler.

[Alatar]

Sorry, I`m forget to subscribe to this ticket and miss your answer.

I disagree with you too =). When you change major version of library (2.8->3.0) you can broke some compatibility. When I read wxStandardPaths docs I was wondered with behaviour of some functions.
For example, for me very strange why function with name GetLocalDataDir returns path in "/etc" (especially on FreeBSD, where "/etc" stores only system config files =)).
Why UserConfigDir is "~" when UserDataDir is "~/.appinfo"?
Why GetConfigDir() returns "/etc", GetDataDir() returns "prefix/share/appinfo" , but GetDocumentsDir() returns "~"?
As I can understand all of this is result of attempts to keep backward compatibility between WX versions.
I want to reduce number of this illogicals, but this will broke compatibility of this class.

If I simple change GetUserConfigDir() to be switchable between old and XDG-compliant, programs that use GetUserDataDir() to get directory for config files still remain XDG-uncompliant. If I make GetUserDataDir() switchable too I`m adding some new illogicals to wxStandardPaths (why program should store they DATA in CONFIG dir and vice versa).
I'm add GetUserAppConfigDir() with behaviour similar to GetDocumentsDir/GetAppDocumentsDir to get app config dir, but this also broke compatibility for programs that already use GetUserDataDir().
So we can broke compatibility or add illogical behaviour. Are you sure, that second is better?

If you require I can add manual switch (UseXDGDirectories()) to this patch but I think it should be XDG-compliant by default, because many programmers do not want to change this option and this would be troubles of end-users =).

By the way, what you think if I add (in separate patch) more cross-platform functions for user dirs, like Download, Music and other?

[vadz]

Replying to Alatar:

I disagree with you too =).

That's fine and I see your point but I still can't agree with it because, as a maintainer of the library who will have to deal with the ire of the users, I have some extra responsibilities.

For example, for me very strange why function with name GetLocalDataDir returns path in "/etc"

This can be explained but I'd prefer to do it on the mailing list rather than in this web interface. But this is definitely intentional.

Why UserConfigDir is "~" when UserDataDir is "~/.appinfo"?
Why GetConfigDir() returns "/etc", GetDataDir() returns "prefix/share/appinfo" , but GetDocumentsDir() returns "~"?

As are all those.

As I can understand all of this is result of attempts to keep backward compatibility between WX versions.

No, they're originally the result of the choices we made. Perhaps some (or all) of these choices were wrong but backwards compatibility has nothing to do with it. It's true that I'd be extremely reluctant to change any of those now because of compatibility however.

If I simple change GetUserConfigDir() to be switchable between old and XDG-compliant, programs that use GetUserDataDir() to get directory for config files still remain XDG-uncompliant. If I make GetUserDataDir() switchable too

Of course all the relevant methods should be affected by this "switch", not only one or two of them.

I'm add GetUserAppConfigDir() with behaviour similar to GetDocumentsDir/GetAppDocumentsDir to get app config dir, but this also broke compatibility for programs that already use GetUserDataDir().

Sorry, I don't see how was the compatibility broken by this.

If you require I can add manual switch (UseXDGDirectories()) to this patch but I think it should be XDG-compliant by default

No, I'm against it, we should avoid silent compatibility breakage as much as possible.

By the way, what you think if I add (in separate patch) more cross-platform functions for user dirs, like Download, Music and other?

Why not. Again, it would probably be better to discuss this on wx-dev first though.

Thanks!

[Alatar]

No, I'm against it, we should avoid silent compatibility breakage as much as possible.

Ok, Im got your point. This is sad for me as a End-User because I dont believe that authors of wx-based software that Im use would change its behaviour from default.

BTW what about WXWIN_COMPATIBILITY_2_8? May be we can use this flag to determine which UseXDGDirectories() value we should use as default?

Sorry, I don't see how was the compatibility broken by this.

Don't take in mind.
I mean that if I change GetUserConfigDir() and not change GetUserDataDir() it can break programs that uses both of them and expect that DataDir is subdir of ConfigDir. But in real world XDG_CONFIG_DIR used for storing only configs but application data too, so I'm agree with GetUserDataDir should be changed too.

This can be explained but I'd prefer to do it on the mailing list rather than in this web interface.

I think, better to explain this in documentation, not here or mailing list ;) Really it is very interesting what is the logic of this methods naming scheme.

[vadz]

Replying to Alatar:

No, I'm against it, we should avoid silent compatibility breakage as much as possible.

Ok, Im got your point. This is sad for me as a End-User because I dont believe that authors of wx-based software that Im use would change its behaviour from default.

BTW what about WXWIN_COMPATIBILITY_2_8? May be we can use this flag to determine which UseXDGDirectories() value we should use as default?

No, sorry, I'm both against breaking compatibility by default and also against the code behaving differently with this symbol defined and without it. It exists only to allow you to completely disable the use of deprecated symbols in your code, not to change the run-time behaviour of your program.

[vadz]

The only thing I can propose would be to have an environment variable that would change the default behaviour. As this would need to be set by the user himself, it would presumably be safe. However I'm not sure if the amount of users who'd bother to set it justifies the extra complexity in the code.

[vadz]

P.S. Resetting the patch checkbox as it can't be applied in the current state.