Review Request 127462: Add support for XDG_*_HOME enviroment variables.

[David Faure]

> On March 24, 2016, 9:15 a.m., Jarosław Staniek wrote:
> > My thoughts mostly related to non-Plasma, non-XDG run environments.
> > 
> > KF5 is a great addition, in hierarchy often sitting aside of Qt, not a part of XDG-compliant desktop. As such we can't say too much about the underlying OS. It may be XDG-compliant but athis can be a decission at various levels: by application developer or on deployment. Things can of course also change after the binary is compiled.
> > 
> > It's hard to see any benefit that apps 'pretend' being XDG-compliant by setting vartiables this way on, say, MS Windows or Mac. Qt applications on these systems do not traditionally alter the OS' paradigm, they are.. just apps, as native as possible/reasonable. Example: there are portable apps (on an USB stick) - I believe we can benefit if we help making them. These apps choose not to integrate too much with what's found on the system, often the user account is shared or temporary.
> > 
> > Setting the variable makes KConfig closer to specific groups of desktop, which is a a small step back. People may be interested in KConfig lib as a general purpose utility in their apps.
> > I'd compare setting the variable this way to setting Windows' USERPROFILE variable on Linux systems, just because it's standard under the former and under Wine. it does not hurt but leaves bad taste.
> > 
> > So the behaviour at least shall be ifdef'd and the ifdef shall depend on OS for which we're building. But if the same binary should behave well in various environments, I am unsure about hardcoding the behaviour. Also I am not sure if this behaviour should be ON by default. I'd rather have it OFF if it's present at all.
> 
> Sandro Knauß wrote:
>     Well I see it the other way around. Without support of XDG variables replacement, we need to use env varaible that are available on all systems f.ex. $HOME, so the only way to set the datalocaltion to write it hardcoded in the config to $HOME/.local/share. This is really ony true for linux for others OSes you want to have other diretories. So now we are able to use XDG_DATA_HOME to be used in kconfig and it will be replaced for linux to $HOME/.local/share, for windows to C:/Users/<USER>/AppData/Local and so on.
>     We use QStandardsPaths for replacing so if the replacement is not correct for an OS this is a bug on Qt side, that should be fixed :D
>     
>     And I can't see how this support can harm anyone - if the env is set this is prefered and only if it is not set it is replaced. No dependecy is added and applications are free to not use it at all. If you use XDG_*_HOME without this patch you will return an empty string for it:
>     
>     i[$e] = $XDG_DATA_HOME/bla
>     
>     -> will return /bla
>     
>     with the patch you will get:
>     $HOME/.local/share/bla ( for linux)
>     C:/Users/<USER>/AppData/Local/bla ( for windows)
>     [...]
> 
> Jarosław Staniek wrote:
>     Before we discuss anything, let's narrow to non-Unix OSes (considering Mac OS X as non-Unix):
>     - Does these OSes use XDG_xxxx to locate anything? I can't spot. 
>     - Isn't it misleading to use the XDG_xxxx variables to pass the locations on these OSes? Don't we have a choice?
>     
>     Digression: I am asking because one quality attribute of KF5 for could be to behave or "think" like Qt would, without spreading a "Unix-y" / "XDG" feel when not really necessary. Non-Unix OSes have own equivalents for many things (e.g. xdg-open), at times these equivalents can be found inferior but we, not being authors of the OSes, can just say "let them be such". We have enough of layers and emulators, subsystems e.g. on Windows (see .NET or chrome-based hybrid apps). Frameworks for developing native apps on these OSes shall not attempt to fix these system facilities but just integrate. Users wanting XDG experience have choice to use XDG-compliant systems...
>     
>     Summing up, an #ifdef and update of documentation would be nice. My 2c...

Indeed a better name for these fake env vars could be QT_DATA_HOME, QT_CONFIG_HOME and QT_CACHE_HOME. In fact I'm thinking more and more that QStandardPaths should support these as real env vars on all OSes --- but that's a separate discussion. For the purposes of this patch, we're faking env vars when they are not set, for the convenience of the config files / desktop files syntax. So these names would work just fine, and would simply be the interface for config files to the QStandardPaths API.


- David


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127462/#review93920
-----------------------------------------------------------


On March 22, 2016, 3:23 p.m., Sandro Knauß wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127462/
> -----------------------------------------------------------
> 
> (Updated March 22, 2016, 3:23 p.m.)
> 
> 
> Review request for KDE Frameworks and Matthew Dawson.
> 
> 
> Repository: kconfig
> 
> 
> Description
> -------
> 
> According to freedesktop specification XDG_*_HOME env varaible should be
> replaced, if they are not setted with default values.
> 
> https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
> 
> as qgetenv only calls getenv, so no path is traslated to it default values. So we have to add this replacement manually. This would help to use XDG_*_HOME more often in configfiles.
> 
> 
> Diffs
> -----
> 
>   autotests/kconfigtest.cpp e92197f3be57ead47b70ca5d040474e7a554c416 
>   src/core/kconfig.cpp 07fa6f552c61c52cc1dd64a1c5fb0e2f00873d50 
> 
> Diff: https://git.reviewboard.kde.org/r/127462/diff/
> 
> 
> Testing
> -------
> 
> Adding tests for XDG_*_HOME variables.
> 
> 
> Thanks,
> 
> Sandro Knauß
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20160325/ed2a5635/attachment.html>