> 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/<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... > > 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 ----------------------------------------------------------- On March 22, 2016, 11:23 a.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, 11:23 a.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
