Summary:
In case a kcfg with arg="true" was used and singleton the static
instance method only accepted a QString config name. This made it
impossible to combine a singleton config with an already existing and
open KSharedConfig::Ptr.
With this change an overloaded instance method is added which takes a
KSharedConfig::Ptr as argument. The private ctor, though, only takes a
KSharedConfig::Ptr and the instance method taking a QString argument
uses KSharedConfig::openConfig on the config file name.
The change is source-incompatible in the following situation:
* kcfgfile arg="true"
* Singleton = true
* Inherits is specified
In this situation the previous revision created an instance method with
a QString argument and passed that to the parent constructor. This is
not in accordance with the documentation. Any user of this behavior was
relying on a bug. With this change now the call to the parent
constructor carries a KSharedConfigPtr.
Test Plan:
kconfigcompiler tests still pass and a config with singleton
and arg="true" generates the code as I need it
Reviewers: #frameworks, dfaure, mdawson
Differential Revision: https://phabricator.kde.org/D3690
Summary:
Better specify the requirements the parent class needs to have.
KConfigCompiler generates different variants of ctors taking either:
* a QStringLiteral argument (name set in <kcfgfile>
* a KSharedConfig::Ptr argument (arg="true" in <kcfgfile>)
* no argument (Inherits=true in kcfgc and no <kcfgfile>)
In order to have Inherits generate compiling code in all cases the
parent class needs to provide accessible ctors.
This change updates the docuementation to reflect this.
Reviewers: #frameworks, dfaure
Differential Revision: https://phabricator.kde.org/D3636
Summary:
In case a kcfg with arg="true" was used and singleton the static
instance method only accepted a QString config name. This made it
impossible to combine a singleton config with an already existing and
open KSharedConfig::Ptr.
With this change an overloaded instance method is added which takes a
KSharedConfig::Ptr as argument. The private ctor, though, only takes a
KSharedConfig::Ptr and the instance method taking a QString argument
uses KSharedConfig::openConfig on the config file name.
This provides full API compatibility and at the same time allows to use
KSharedConfig in addition to the arg name based variant.
Test Plan:
kconfigcompiler tests still pass and a config with singleton
and arg="true" generates the code as I need it
Reviewers: #frameworks
Differential Revision: https://phabricator.kde.org/D3386
REVIEW:128102
Set encoding on kconfig_compiler generated cpp and headers
to utf-8 ( reproducible builds ) Under certain locals non
standard characters will get dropped making builds un reproducible.
Setting the encoding to utf-8 on the files makes all builds reproducible
no matter what ( or none ) locale is in use. Thereby making the build reproducible.
Previously, if a .desktop file had a TryExec and a X-KDE-AuthorizeAction
entry we would skip the KAuthorized check. This is clearly wrong.
REVIEW: 127948
The typedef is copied here to avoid including the header that contains
it. However, this confuses sip if binding definitions are generated
from the C++ headers. Simply inline the typedef instead.
Inside desktop files we want to reach also data, cache and config home
to create files inside these directories.
REVIEW: 127462
CHANGELOG: Add support for get QStandardPaths locations inside desktop files.
These fields should all be written to before they are read during normal
operation, but this ensures they have a sensible default in case they are not.
Coverity issue 1291513.
This seems to be left over from KDE 3.5 times, and isn't referenced anywhere
in the code. Since its a private header, just remove.
Found by Coverity, issue 1175531.
REVIEW: 126555
During a kconf_update run, an invalid group name may be treated as correct
even though the name failed to unescape. This leads the group name to be
a null character, which will fail.
If the unescape failed, return that failure status instead. This should have
no impact, as the previous result would have been wrong anyways. Now a
more useful diagnostic will be returned instead.
Update the unit tests to ensure this issue is tested in the future.
Found in Coverity issue 258087.
REVIEW: 126556