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

[Matthew Dawson]

> On March 24, 2016, 5: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//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//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_ to locate anything? I can't spot. 
> - Isn't it misleading to use the XDG_ 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...
> 
> David Faure wrote:
> 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.

+1 from me on this suggestion.  I'm good with this change if the names are 
changed and David's other points are addressed.


- Matthew


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

Re: 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//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//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_ to locate anything? I can't spot. 
> - Isn't it misleading to use the XDG_ 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:
> 
> ---

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

[Jarosław Staniek]

> On March 24, 2016, 10: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//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//AppData/Local/bla ( for windows)
> [...]

Before we discuss anything, let's narrow to non-Unix OSes (considering Mac OS X 
as non-Unix):
- Does these OSes use XDG_ to locate anything? I can't spot. 
- Isn't it misleading to use the XDG_ 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...


- Jarosław


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


On March 22, 2016, 4: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, 4: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 pat

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

[Sandro Knauß]

> On März 24, 2016, 9:15 vorm., 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.

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//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//AppData/Local/bla ( for windows)
[...]


- Sandro


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


On März 22, 2016, 3:23 nachm., Sandro Knauß wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127462/
> ---
> 
> (Updated März 22, 2016, 3:23 nachm.)
> 
> 
> 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ß
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

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

[Sandro Knauß]

> On März 24, 2016, 8:16 vorm., David Faure wrote:
> > autotests/kconfigtest.cpp, line 536
> > 
> >
> > Why? On my system this wouldn't pass.
> > If you want to make sure it's empty, use qunsetenv.

Okay I mostly written this, to get a first impression if the patch will enter 
kconfig.
for sure we need a test with XDG env set to a value, and one where XDG is not 
set. To test both ways.


> On März 24, 2016, 8:16 vorm., David Faure wrote:
> > autotests/kconfigtest.cpp, line 538
> > 
> >
> > writableLocaion, not displayName.
> > 
> > This shows the limitations of a unittest that uses the same code in the 
> > code and in the test. If both are wrong, the test still passes :-)

Do you have a better solution for getting away from "a unittest that uses the 
same code" in this case?


- Sandro


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


On März 22, 2016, 3:23 nachm., Sandro Knauß wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127462/
> ---
> 
> (Updated März 22, 2016, 3:23 nachm.)
> 
> 
> 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ß
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

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

[Jarosław Staniek]

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



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.

- Jarosław Staniek


On March 22, 2016, 4: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, 4: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ß
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

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

[David Faure]

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



It's a bit of a stretch to say that the XDG base dir spec says that env vars in 
config files and desktop files should work even if they are not set :)
First, because support for env vars in desktop files ([$e]) is a KDE extension 
IIRC, and secondly because the base dir spec only gives default values for 
these locations, while [$e] was strictly supposed to be about env var expansion.
This being said, I see no harm in extending that to support the default values 
as if they were set in the env var. Just the commit log should be a bit more 
like "add a feature" than "the spec tells us to do this".


autotests/kconfigtest.cpp (line 511)


noeol was supposed to be the line with no EOL. Leave it as the last 
position.



autotests/kconfigtest.cpp (line 536)


Why? On my system this wouldn't pass.
If you want to make sure it's empty, use qunsetenv.



autotests/kconfigtest.cpp (line 538)


writableLocaion, not displayName.

This shows the limitations of a unittest that uses the same code in the 
code and in the test. If both are wrong, the test still passes :-)



src/core/kconfig.cpp (line 226)


displayName?? You want writableLocation here.


- David Faure


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ß
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

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

[Sandro Knauß]

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

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ß

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel