Re: kconfig question
On Thursday 28 January 2016 10:06:29 Ralf Habacker wrote: > > In a similar patch I wrote recently for testing > https://build.opensuse.org/package/view_file/home:rhabacker:branches:windows:mingw:win32:Qt55/mingw32-libqt5-qtbase/0001-Add-QStandardPaths-support-for-qt.conf.patch?expand=1 > I used QLibraryInfo::location(PrefixPath) as base. Interesting. Are you going to submit this to Qt gerrit ? -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kconfig question
On Wed, 27 Jan 2016, Matthew Dawson wrote: Won't this change the behaviour from Unix like systems? They won't have the Krita folder in the name, so they will just get dumped in the common config folder. I don't think carrying a patch like that for KConfig is a good idea. Yes, but that's exactly what I need. I need Krita to behave differently on Windows than on Linux. On Windows, everything goes into Roaming\krita, on Linux it goes wherever it goes by default, even though that's harder to to explain to users. -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kconfig question
On Wednesday 27 January 2016 10:32:50 Boudewijn Rempt wrote:
> On Sat, 23 Jan 2016, David Faure wrote:
>
> >
> > Not sure this answers Boud's question, since he *is* seeing "Local" on
> > Windows.
> > He said: "I noticed that krita on windows wrote its kritarc to
> > Roaming\local\ or Local\local "
>
> Hm, looks like that was a sideeffect of something else I tried, it's now in
> Roaming\Local
>
> >
> > According to the QStandardPaths documentation, it is expected to see
> > something like "C:/Users//AppData/Local" in the paths for
> > GenericConfigLocation
> >
> > The the lowercase "local" after that puzzles me. I wonder where that comes
> > from,
> > it's not anywhere in the QStandardPaths code for Windows, nor KConfig
> > AFAICS.
> >
> > Boud, how is KConfig called exactly?
> > (I don't mean "it's called KConfig" ;-) I mean what does the code using
> > it, look like?
> > I think this needs some debugging to find out where this "local" string
> > comes from)
>
> Well, it's done in a lot of places, about 160, like:
>
> KConfigGroup cfg =
> KSharedConfig::openConfig()->group("advancedColorSelector");
>
> or
>
> KConfigGroup cg(KSharedConfig::openConfig(), "");
>
>
> What I want in the end is have AppData\Roaming\Krita\ where both kritarc and
> the user's
> custom resources are saved, like brushes and so on. I'm fine with patching
> kconfig for
> windows for that, though.
>
> > Don't forget that KConfig is also used by libraries, not just by
> > applications.
> > Let's pick a random example: KIO, which stores the KFileWidget mode (icon
> > or list) that the user prefers.
> > Right now this is global, it affects all applications. If you make KConfig
> > use AppConfigLocation
> > by default, then suddenly this setting is per application. Maybe no big
> > deal for this particular one,
> > but imagine having to select your spellcheck dictionaries in all apps or
> > .
>
> Well, those are resources, aren't they? Not config files. But I confuse
> myself all the time, too, with those two.
>
> > In general, I don't like AppConfigLocation, we've been bitten by "appdata"
> > too much in kde4 times, same issue:
> > some code starts as app code, it uses such an app-specific location type,
> > then it's moved to a library,
> > and that breaks sharing data between apps (example: kmail identities,
> > initially in kmail, then one day
> > moved to a library --> definitely want the identities to be shared, not per
> > app). But I guess that's my
> > "library developer" point of view, I can understand that application
> > developers don't want to hardcode
> > "krita/kritarc" everywhere...
>
> Yes... But given that I need to build kconfig on windows myself anyway, I
> guess I can just patch that. In the
> beginning I was just wondering wether this was the right behaviour.
Sounds to me like Patrick's pending patch to add configurable paths in
QStandardPaths using qt.conf
would work exactly right for this. Your windows installer for krita would
install a qt.conf where
GenericConfigLocation = [...]\AppData\Roaming\Krita.
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5
>From c6524a252fc362abe5b8412dcabec499ff092143 Mon Sep 17 00:00:00 2001
From: Patrick Spendrin
Date: Tue, 29 Sep 2015 15:47:09 +0200
Subject: [PATCH] WIP: configurable standardpaths
---
src/corelib/global/global.pri | 1 +
src/corelib/global/qlibraryinfo.cpp | 49 +---
src/corelib/global/qlibraryinfo_p.h | 61 +++
src/corelib/io/qstandardpaths.cpp | 42
src/corelib/io/qstandardpaths.h | 2 ++
src/corelib/io/qstandardpaths_mac.mm | 4 +++
src/corelib/io/qstandardpaths_win.cpp | 4 ++-
7 files changed, 136 insertions(+), 27 deletions(-)
create mode 100644 src/corelib/global/qlibraryinfo_p.h
diff --git a/src/corelib/global/global.pri b/src/corelib/global/global.pri
index 6a8104b..a905cb2 100644
--- a/src/corelib/global/global.pri
+++ b/src/corelib/global/global.pri
@@ -10,6 +10,7 @@ HEADERS += \
global/qnumeric_p.h \
global/qnumeric.h \
global/qglobalstatic.h \
+global/qlibraryinfo_p.h \
global/qlibraryinfo.h \
global/qlogging.h \
global/qtypeinfo.h \
diff --git a/src/corelib/global/qlibraryinfo.cpp b/src/corelib/global/qlibraryinfo.cpp
index 0cfcc4e..640e9cf 100644
--- a/src/corelib/global/qlibraryinfo.cpp
+++ b/src/corelib/global/qlibraryinfo.cpp
@@ -38,6 +38,7 @@
#include "qsettings.h"
#include "qlibraryinfo.h"
#include "qscopedpointer.h"
+#include "qlibraryinfo_p.h"
#ifdef QT_BUILD_QMAKE
QT_BEGIN_NAMESPACE
@@ -77,37 +78,33 @@ struct QLibrarySettings
};
Q_GLOBAL_STATIC(QLibrarySettings, qt_library_settings)
-class QLibraryInfoPrivate
-{
-public:
-static QSettings *findConfiguration();
#ifdef QT_BUILD_QMAKE
-static bool haveGroup(QLibraryInfo::PathGroup group)
-{
-
Re: kconfig question
Am 28.01.2016 um 09:48 schrieb David Faure:
> On Wednesday 27 January 2016 10:32:50 Boudewijn Rempt wrote:
>> On Sat, 23 Jan 2016, David Faure wrote:
>>
>>> Not sure this answers Boud's question, since he *is* seeing "Local" on
>>> Windows.
>>> He said: "I noticed that krita on windows wrote its kritarc to
>>> Roaming\local\ or Local\local "
>> Hm, looks like that was a sideeffect of something else I tried, it's now in
>> Roaming\Local
>>
>>> According to the QStandardPaths documentation, it is expected to see
>>> something like "C:/Users//AppData/Local" in the paths for
>>> GenericConfigLocation
>>>
>>> The the lowercase "local" after that puzzles me. I wonder where that comes
>>> from,
>>> it's not anywhere in the QStandardPaths code for Windows, nor KConfig
>>> AFAICS.
>>>
>>> Boud, how is KConfig called exactly?
>>> (I don't mean "it's called KConfig" ;-) I mean what does the code using
>>> it, look like?
>>> I think this needs some debugging to find out where this "local" string
>>> comes from)
>> Well, it's done in a lot of places, about 160, like:
>>
>> KConfigGroup cfg =
>> KSharedConfig::openConfig()->group("advancedColorSelector");
>>
>> or
>>
>> KConfigGroup cg(KSharedConfig::openConfig(), "");
>>
>>
>> What I want in the end is have AppData\Roaming\Krita\ where both kritarc and
>> the user's
>> custom resources are saved, like brushes and so on. I'm fine with patching
>> kconfig for
>> windows for that, though.
>>
>>> Don't forget that KConfig is also used by libraries, not just by
>>> applications.
>>> Let's pick a random example: KIO, which stores the KFileWidget mode (icon
>>> or list) that the user prefers.
>>> Right now this is global, it affects all applications. If you make KConfig
>>> use AppConfigLocation
>>> by default, then suddenly this setting is per application. Maybe no big
>>> deal for this particular one,
>>> but imagine having to select your spellcheck dictionaries in all apps or
>>> .
>> Well, those are resources, aren't they? Not config files. But I confuse
>> myself all the time, too, with those two.
>>
>>> In general, I don't like AppConfigLocation, we've been bitten by "appdata"
>>> too much in kde4 times, same issue:
>>> some code starts as app code, it uses such an app-specific location type,
>>> then it's moved to a library,
>>> and that breaks sharing data between apps (example: kmail identities,
>>> initially in kmail, then one day
>>> moved to a library --> definitely want the identities to be shared, not per
>>> app). But I guess that's my
>>> "library developer" point of view, I can understand that application
>>> developers don't want to hardcode
>>> "krita/kritarc" everywhere...
>> Yes... But given that I need to build kconfig on windows myself anyway, I
>> guess I can just patch that. In the
>> beginning I was just wondering wether this was the right behaviour.
> Sounds to me like Patrick's pending patch to add configurable paths in
> QStandardPaths using qt.conf
> would work exactly right for this. Your windows installer for krita would
> install a qt.conf where
> GenericConfigLocation = [...]\AppData\Roaming\Krita.
>From the patch I do not see how it resolves relative pathes which is
very important on Windows.
In a similar patch I wrote recently for testing
https://build.opensuse.org/package/view_file/home:rhabacker:branches:windows:mingw:win32:Qt55/mingw32-libqt5-qtbase/0001-Add-QStandardPaths-support-for-qt.conf.patch?expand=1
I used QLibraryInfo::location(PrefixPath) as base.
Ralf
>
>
> ___
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kconfig question
On Thu, 28 Jan 2016, David Faure wrote: Sounds to me like Patrick's pending patch to add configurable paths in QStandardPaths using qt.conf would work exactly right for this. Your windows installer for krita would install a qt.conf where GenericConfigLocation = [...]\AppData\Roaming\Krita. Sounds like it would be a good solution indeed! -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kconfig question
On Wednesday, January 27, 2016 10:32:50 AM EST Boudewijn Rempt wrote:
> On Sat, 23 Jan 2016, David Faure wrote:
> > (I don't mean "it's called KConfig" ;-) I mean what does the code using
> > it, look like? I think this needs some debugging to find out where this
> > "local" string comes from)
> Well, it's done in a lot of places, about 160, like:
>
> KConfigGroup cfg =
> KSharedConfig::openConfig()->group("advancedColorSelector");
>
> or
>
> KConfigGroup cg(KSharedConfig::openConfig(), "");
>
>
> What I want in the end is have AppData\Roaming\Krita\ where both kritarc and
> the user's custom resources are saved, like brushes and so on. I'm fine
> with patching kconfig for windows for that, though.
Won't this change the behaviour from Unix like systems? They won't have the
Krita folder in the name, so they will just get dumped in the common config
folder. I don't think carrying a patch like that for KConfig is a good idea.
--
Matthew
signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kconfig question
On Sat, 23 Jan 2016, David Faure wrote:
Not sure this answers Boud's question, since he *is* seeing "Local" on Windows.
He said: "I noticed that krita on windows wrote its kritarc to Roaming\local\ or
Local\local "
Hm, looks like that was a sideeffect of something else I tried, it's now in
Roaming\Local
According to the QStandardPaths documentation, it is expected to see
something like "C:/Users//AppData/Local" in the paths for
GenericConfigLocation
The the lowercase "local" after that puzzles me. I wonder where that comes from,
it's not anywhere in the QStandardPaths code for Windows, nor KConfig AFAICS.
Boud, how is KConfig called exactly?
(I don't mean "it's called KConfig" ;-) I mean what does the code using it,
look like?
I think this needs some debugging to find out where this "local" string comes
from)
Well, it's done in a lot of places, about 160, like:
KConfigGroup cfg =
KSharedConfig::openConfig()->group("advancedColorSelector");
or
KConfigGroup cg(KSharedConfig::openConfig(), "");
What I want in the end is have AppData\Roaming\Krita\ where both kritarc and
the user's
custom resources are saved, like brushes and so on. I'm fine with patching
kconfig for
windows for that, though.
Don't forget that KConfig is also used by libraries, not just by applications.
Let's pick a random example: KIO, which stores the KFileWidget mode (icon or
list) that the user prefers.
Right now this is global, it affects all applications. If you make KConfig use
AppConfigLocation
by default, then suddenly this setting is per application. Maybe no big deal
for this particular one,
but imagine having to select your spellcheck dictionaries in all apps or .
Well, those are resources, aren't they? Not config files. But I confuse myself
all the time, too, with those two.
In general, I don't like AppConfigLocation, we've been bitten by "appdata" too
much in kde4 times, same issue:
some code starts as app code, it uses such an app-specific location type, then
it's moved to a library,
and that breaks sharing data between apps (example: kmail identities, initially
in kmail, then one day
moved to a library --> definitely want the identities to be shared, not per
app). But I guess that's my
"library developer" point of view, I can understand that application developers
don't want to hardcode
"krita/kritarc" everywhere...
Yes... But given that I need to build kconfig on windows myself anyway, I guess
I can just patch that. In the
beginning I was just wondering wether this was the right behaviour.
--
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kconfig question
On Monday 18 January 2016 10:28:18 Matthew Dawson wrote: > On Monday, January 18, 2016 8:53:22 AM EST Boudewijn Rempt wrote: > > On Sun, 17 Jan 2016, Matthew Dawson wrote: > > > It appears this is the desired behaviour. On most platforms, > > > GenericConfigLocation and ConfigLocation are the same things, except > > > Windows. According to Qt's history, ConfigLocation was supposed to act > > > like GenericConfigLocation, but a mistake was made and > > > GenericConfigLocation was introduced to fix that without breaking > > > existing applications. See commit > > > 44d48862c0ff4b67a76734deae5e76f926a77bce . > > > > > > KConfig was then changed to use GenericConfigLocation as well, see commit > > > b3487a0684fa464ada0cd3407e96d0406345a42a in kdelibs (this happened before > > > the split). On all platforms except Windows, that is how KConfig has all > > > behaved. Even in KDE4, config files were often put in the same directory, > > > just not a standard directory shared by the platform. > > > > > > Based on the commit history, I'd say it makes sense. Anything else would > > > yield platform inconsistent behaviour, which is more likely to confuse > > > people. If ConfigLocation wasn't inconsistent across platforms, that > > > would be a different story. > > > > Hm, but I don't think that having kritarc in a directory called "local" on > > every platform is important: the important thing is to have it in the > > location that's "normal" on those platforms. > Taking a quick look at my Win7 machine suggests that the path Qt uses for > GenericConfigLocation is a mix of .config/.local/.cache on *nix. According > to > Qt's documents, no other system uses a local/ folder for > GenericConfigLocation. So that seems "normal". Not sure this answers Boud's question, since he *is* seeing "Local" on Windows. He said: "I noticed that krita on windows wrote its kritarc to Roaming\local\ or Local\local " According to the QStandardPaths documentation, it is expected to see something like "C:/Users//AppData/Local" in the paths for GenericConfigLocation The the lowercase "local" after that puzzles me. I wonder where that comes from, it's not anywhere in the QStandardPaths code for Windows, nor KConfig AFAICS. Boud, how is KConfig called exactly? (I don't mean "it's called KConfig" ;-) I mean what does the code using it, look like? I think this needs some debugging to find out where this "local" string comes from) > > > Regardless, changing the default behaviour now is a no go, as that would > > > break everyone's setup. However, I wouldn't be opposed to a method to > > > allow KConfig to easily store config files in an application appropriate > > > folder. It couldn't break existing applications though. I also don't > > > think most things should need it anyways, since most applications only > > > have one config file. Something like akonadi (which already uses a > > > subfolder in my .config) makes sense, and I could see it making sense for > > > Krita. Maybe some way to use AppConfigLocation? We'd have to be careful > > > with that though, since it's> > > > >=5.5. > > > > I'm fine with 5.5 as a minimum for my own purposes :-). I just don't want to > > have to change a couple of hundred locations to explicitly pass > > AppConfigLocation. > I meant that a patch for KConfig would have to be careful, since KConfig > can't > depend on 5.5 (yet). I think just using the defaults will be ok, if you have > only one config file. If you have more, then I'd agree that > AppConfigLocation > seems better. Don't forget that KConfig is also used by libraries, not just by applications. Let's pick a random example: KIO, which stores the KFileWidget mode (icon or list) that the user prefers. Right now this is global, it affects all applications. If you make KConfig use AppConfigLocation by default, then suddenly this setting is per application. Maybe no big deal for this particular one, but imagine having to select your spellcheck dictionaries in all apps or . In general, I don't like AppConfigLocation, we've been bitten by "appdata" too much in kde4 times, same issue: some code starts as app code, it uses such an app-specific location type, then it's moved to a library, and that breaks sharing data between apps (example: kmail identities, initially in kmail, then one day moved to a library --> definitely want the identities to be shared, not per app). But I guess that's my "library developer" point of view, I can understand that application developers don't want to hardcode "krita/kritarc" everywhere... -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kconfig question
On Saturday, January 23, 2016 11:54:56 AM EST David Faure wrote: > On Monday 18 January 2016 10:28:18 Matthew Dawson wrote: > > On Monday, January 18, 2016 8:53:22 AM EST Boudewijn Rempt wrote: > > > On Sun, 17 Jan 2016, Matthew Dawson wrote: > > > > It appears this is the desired behaviour. On most platforms, > > > > GenericConfigLocation and ConfigLocation are the same things, except > > > > Windows. According to Qt's history, ConfigLocation was supposed to act > > > > like GenericConfigLocation, but a mistake was made and > > > > GenericConfigLocation was introduced to fix that without breaking > > > > existing applications. See commit > > > > 44d48862c0ff4b67a76734deae5e76f926a77bce . > > > > > > > > KConfig was then changed to use GenericConfigLocation as well, see > > > > commit > > > > b3487a0684fa464ada0cd3407e96d0406345a42a in kdelibs (this happened > > > > before > > > > the split). On all platforms except Windows, that is how KConfig has > > > > all > > > > behaved. Even in KDE4, config files were often put in the same > > > > directory, > > > > just not a standard directory shared by the platform. > > > > > > > > Based on the commit history, I'd say it makes sense. Anything else > > > > would > > > > yield platform inconsistent behaviour, which is more likely to confuse > > > > people. If ConfigLocation wasn't inconsistent across platforms, that > > > > would be a different story. > > > > > > Hm, but I don't think that having kritarc in a directory called "local" > > > on > > > every platform is important: the important thing is to have it in the > > > location that's "normal" on those platforms. > > > > Taking a quick look at my Win7 machine suggests that the path Qt uses for > > GenericConfigLocation is a mix of .config/.local/.cache on *nix. > > According to Qt's documents, no other system uses a local/ folder for > > GenericConfigLocation. So that seems "normal". > > Not sure this answers Boud's question, since he *is* seeing "Local" on > Windows. He said: "I noticed that krita on windows wrote its kritarc to > Roaming\local\ or Local\local " > > According to the QStandardPaths documentation, it is expected to see > something like "C:/Users//AppData/Local" in the paths for > GenericConfigLocation > > The the lowercase "local" after that puzzles me. I wonder where that comes > from, it's not anywhere in the QStandardPaths code for Windows, nor KConfig > AFAICS. I thought he mean Romaing\ or Local\ to be the path to AppData, where roaming or local changed based upon how the Windows profile was setup. The second local\ I had assumed was coming from Qt, since it appeared in both. If that was not the intent, then I apologize and agree with David. If that is the case, I'll try and do some digging. I just don't have a Windows machine handy I can do this on. > > Boud, how is KConfig called exactly? > (I don't mean "it's called KConfig" ;-) I mean what does the code using > it, look like? I think this needs some debugging to find out where this > "local" string comes from) > > > > Regardless, changing the default behaviour now is a no go, as that > > > > would > > > > break everyone's setup. However, I wouldn't be opposed to a method to > > > > allow KConfig to easily store config files in an application > > > > appropriate > > > > folder. It couldn't break existing applications though. I also don't > > > > think most things should need it anyways, since most applications only > > > > have one config file. Something like akonadi (which already uses a > > > > subfolder in my .config) makes sense, and I could see it making sense > > > > for > > > > Krita. Maybe some way to use AppConfigLocation? We'd have to be > > > > careful > > > > with that though, since it's> > > > > > > > > >=5.5. > > > > > > I'm fine with 5.5 as a minimum for my own purposes :-). I just don't > > > want to have to change a couple of hundred locations to explicitly pass > > > AppConfigLocation. > > > > I meant that a patch for KConfig would have to be careful, since KConfig > > can't depend on 5.5 (yet). I think just using the defaults will be ok, > > if you have only one config file. If you have more, then I'd agree that > > AppConfigLocation seems better. > > Don't forget that KConfig is also used by libraries, not just by > applications. Let's pick a random example: KIO, which stores the > KFileWidget mode (icon or list) that the user prefers. Right now this is > global, it affects all applications. If you make KConfig use > AppConfigLocation by default, then suddenly this setting is per > application. Maybe no big deal for this particular one, but imagine having > to select your spellcheck dictionaries in all apps or global settings here>. I wasn't thinking the default should change, as applications would lose their preferences as the config files are looked for in a different location. Regarding library use, I agree that even allowing an app developer to change the default could be
Re: kconfig question
On Monday, January 18, 2016 8:53:22 AM EST Boudewijn Rempt wrote: > On Sun, 17 Jan 2016, Matthew Dawson wrote: > > It appears this is the desired behaviour. On most platforms, > > GenericConfigLocation and ConfigLocation are the same things, except > > Windows. According to Qt's history, ConfigLocation was supposed to act > > like GenericConfigLocation, but a mistake was made and > > GenericConfigLocation was introduced to fix that without breaking > > existing applications. See commit > > 44d48862c0ff4b67a76734deae5e76f926a77bce . > > > > KConfig was then changed to use GenericConfigLocation as well, see commit > > b3487a0684fa464ada0cd3407e96d0406345a42a in kdelibs (this happened before > > the split). On all platforms except Windows, that is how KConfig has all > > behaved. Even in KDE4, config files were often put in the same directory, > > just not a standard directory shared by the platform. > > > > Based on the commit history, I'd say it makes sense. Anything else would > > yield platform inconsistent behaviour, which is more likely to confuse > > people. If ConfigLocation wasn't inconsistent across platforms, that > > would be a different story. > > Hm, but I don't think that having kritarc in a directory called "local" on > every platform is important: the important thing is to have it in the > location that's "normal" on those platforms. Taking a quick look at my Win7 machine suggests that the path Qt uses for GenericConfigLocation is a mix of .config/.local/.cache on *nix. According to Qt's documents, no other system uses a local/ folder for GenericConfigLocation. So that seems "normal". > > > Regardless, changing the default behaviour now is a no go, as that would > > break everyone's setup. However, I wouldn't be opposed to a method to > > allow KConfig to easily store config files in an application appropriate > > folder. It couldn't break existing applications though. I also don't > > think most things should need it anyways, since most applications only > > have one config file. Something like akonadi (which already uses a > > subfolder in my .config) makes sense, and I could see it making sense for > > Krita. Maybe some way to use AppConfigLocation? We'd have to be careful > > with that though, since it's> > > >=5.5. > > I'm fine with 5.5 as a minimum for my own purposes :-). I just don't want to > have to change a couple of hundred locations to explicitly pass > AppConfigLocation. I meant that a patch for KConfig would have to be careful, since KConfig can't depend on 5.5 (yet). I think just using the defaults will be ok, if you have only one config file. If you have more, then I'd agree that AppConfigLocation seems better. -- Matthew signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kconfig question
On Sun, 17 Jan 2016, Matthew Dawson wrote: It appears this is the desired behaviour. On most platforms, GenericConfigLocation and ConfigLocation are the same things, except Windows. According to Qt's history, ConfigLocation was supposed to act like GenericConfigLocation, but a mistake was made and GenericConfigLocation was introduced to fix that without breaking existing applications. See commit 44d48862c0ff4b67a76734deae5e76f926a77bce . KConfig was then changed to use GenericConfigLocation as well, see commit b3487a0684fa464ada0cd3407e96d0406345a42a in kdelibs (this happened before the split). On all platforms except Windows, that is how KConfig has all behaved. Even in KDE4, config files were often put in the same directory, just not a standard directory shared by the platform. Based on the commit history, I'd say it makes sense. Anything else would yield platform inconsistent behaviour, which is more likely to confuse people. If ConfigLocation wasn't inconsistent across platforms, that would be a different story. Hm, but I don't think that having kritarc in a directory called "local" on every platform is important: the important thing is to have it in the location that's "normal" on those platforms. Regardless, changing the default behaviour now is a no go, as that would break everyone's setup. However, I wouldn't be opposed to a method to allow KConfig to easily store config files in an application appropriate folder. It couldn't break existing applications though. I also don't think most things should need it anyways, since most applications only have one config file. Something like akonadi (which already uses a subfolder in my .config) makes sense, and I could see it making sense for Krita. Maybe some way to use AppConfigLocation? We'd have to be careful with that though, since it's >=5.5. I'm fine with 5.5 as a minimum for my own purposes :-). I just don't want to have to change a couple of hundred locations to explicitly pass AppConfigLocation. -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kconfig question
On Friday, January 15, 2016 9:46:00 AM EST Boudewijn Rempt wrote: > I noticed that krita on windows wrote its kritarc to Roaming\local\ or > Local\local instead of Roaming\krita\kritarc, and I was wondering why that > was. I now think it's because KConfig's default is to write to > GenericConfigLocation instead of ConfigLocation. > > Is that really intended to be the default for kconfig? I guess it's wrong > for pretty much 100% of applications that use kconfig, because pretty much > every application should write its config to ConfigLocation instead. > > There are a couple of hundred places in Krita where a config object is > retrieved and before I start adapting all those by adding two extra > parameter (or writing a wrapper around kconfig, or something else...) I'd > like to know why GenericConfigLocation is the default :-) It appears this is the desired behaviour. On most platforms, GenericConfigLocation and ConfigLocation are the same things, except Windows. According to Qt's history, ConfigLocation was supposed to act like GenericConfigLocation, but a mistake was made and GenericConfigLocation was introduced to fix that without breaking existing applications. See commit 44d48862c0ff4b67a76734deae5e76f926a77bce . KConfig was then changed to use GenericConfigLocation as well, see commit b3487a0684fa464ada0cd3407e96d0406345a42a in kdelibs (this happened before the split). On all platforms except Windows, that is how KConfig has all behaved. Even in KDE4, config files were often put in the same directory, just not a standard directory shared by the platform. Based on the commit history, I'd say it makes sense. Anything else would yield platform inconsistent behaviour, which is more likely to confuse people. If ConfigLocation wasn't inconsistent across platforms, that would be a different story. Regardless, changing the default behaviour now is a no go, as that would break everyone's setup. However, I wouldn't be opposed to a method to allow KConfig to easily store config files in an application appropriate folder. It couldn't break existing applications though. I also don't think most things should need it anyways, since most applications only have one config file. Something like akonadi (which already uses a subfolder in my .config) makes sense, and I could see it making sense for Krita. Maybe some way to use AppConfigLocation? We'd have to be careful with that though, since it's >=5.5. -- Matthew signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
