Summary:
Fix the following bug, if an entry is set on HOME/.config/kdeglobals and on a specific config file like kcmfonts
When you hit restore defaults button and apply, value will be not wrote on the specific file, but then the value is the one from kdeglobals
This patch ensure we write the key to the specific configuration file on those case with an empty value. KConfig will take default value automatically
Test Plan:
Added a test to ensure flag is working
Tested using some KCM to ensure all is working fine
Reviewers: ervin, dfaure, meven, crossi, hchain
Reviewed By: ervin, dfaure, meven
Subscribers: kde-frameworks-devel
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D28128
Summary:
- When GenerateProperties and Mutators are activated, the generated code
did not handle min/max properly
- In the case of a parameterized entry, generated code also did not
handle min/max
BUG: 418146
Test Plan: - auto tests included
Reviewers: meven, crossi, ervin, bport, tcanabrava
Reviewed By: meven, ervin
Subscribers: kde-frameworks-devel
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D27497
Summary:
The current KConfigXT compiler is in a sad state:
It's a massive file with loads of global variables that handle state, the generator is done within the main() function and it seems to have grown organically. There are no classes to separate logic / state / generation, what exists is code that generates code from a xml / ini pair, but it's hard to even discover what a bit of code is doing. The code istyle is C++ / Java from the nineties, which is not bad per see but it also uses quite a few things that are going to be deprecated in Qt 6 so I'm also taking the time make the code more streamlined with newer code style (no iterators, lambdas, auto usage, etc).
The code that generates the files simplly pushes strings to a text stream, and it's hard to figure out when something starts or something ends: for instance, the code that generates the Constructor has more than sixty lines of code englobing some nested if - for - if - for constructs.
Currently the code is "done" - there's one bug that I still need to find & fix regarding Translations, but the rest seems sane.
The current testcode generates incorrect *whitespaces* regarding the old code (there's some parts that I feel that it's important to fix before merging, but overall, the whitespace changes are not bad and easier to handle, old code had a hand-counted amount of spaces before each line, new code has a function whitespace() that adds the current-and-correct amount of whitespaces based on indentation level that you start by startScope() and ends with endScope(). rest of the code still needs to be ported to it.
I plan to fix the testcases whitespace by manually adding them, I'v fougth with the code for a while and added a few hacks there but I don't want to make the code hackish again.
New code is not perfect by any means, but is a good step in the right direction.
This code tries to Separate the compiler code into many different files / classes to be more obvious what's happening, and each class also has many helper methods to minimize copypaste.
- CodeGenerator: Has base code for the header and source files that can be shared
- HeaderGenerator: Logic for generating the header file
- SourceGenerator: Logic for generating the source file
- KcfgParser: Logic for parsing the kcfg file and extracting the information from the Xml file
- CommonStructs: a header that contains the structs that are currently used everywhere.
- KConfigParameters: (was CfgConfig - ConfigConfig, wat) - Has information passed via the kcfgc file
- kcfg_compiler - will be renamed to main - start the other classes and generates the files.
This code here currently has the begining of this separation, with the CodeGenerator and the HeaderGenerator in a ~good~ state, but unfinished.
Test Plan:
- Run the test cases,
- Compare the diffs generated by the testcases and fix in the code the errors / differences
- Run and compare real kde source with the new and old generators to look for errors
Reviewers: #frameworks, ervin, bport, dfaure
Reviewed By: dfaure
Subscribers: davidre, bcooksley, cgiboudeaux, kossebau, bport, ngraham, kde-frameworks-devel
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D26202
Summary:
The current KConfigXT compiler is in a sad state:
It's a massive file with loads of global variables that handle state, the generator is done within the main() function and it seems to have grown organically. There are no classes to separate logic / state / generation, what exists is code that generates code from a xml / ini pair, but it's hard to even discover what a bit of code is doing. The code istyle is C++ / Java from the nineties, which is not bad per see but it also uses quite a few things that are going to be deprecated in Qt 6 so I'm also taking the time make the code more streamlined with newer code style (no iterators, lambdas, auto usage, etc).
The code that generates the files simplly pushes strings to a text stream, and it's hard to figure out when something starts or something ends: for instance, the code that generates the Constructor has more than sixty lines of code englobing some nested if - for - if - for constructs.
Currently the code is "done" - there's one bug that I still need to find & fix regarding Translations, but the rest seems sane.
The current testcode generates incorrect *whitespaces* regarding the old code (there's some parts that I feel that it's important to fix before merging, but overall, the whitespace changes are not bad and easier to handle, old code had a hand-counted amount of spaces before each line, new code has a function whitespace() that adds the current-and-correct amount of whitespaces based on indentation level that you start by startScope() and ends with endScope(). rest of the code still needs to be ported to it.
I plan to fix the testcases whitespace by manually adding them, I'v fougth with the code for a while and added a few hacks there but I don't want to make the code hackish again.
New code is not perfect by any means, but is a good step in the right direction.
This code tries to Separate the compiler code into many different files / classes to be more obvious what's happening, and each class also has many helper methods to minimize copypaste.
- CodeGenerator: Has base code for the header and source files that can be shared
- HeaderGenerator: Logic for generating the header file
- SourceGenerator: Logic for generating the source file
- KcfgParser: Logic for parsing the kcfg file and extracting the information from the Xml file
- CommonStructs: a header that contains the structs that are currently used everywhere.
- KConfigParameters: (was CfgConfig - ConfigConfig, wat) - Has information passed via the kcfgc file
- kcfg_compiler - will be renamed to main - start the other classes and generates the files.
This code here currently has the begining of this separation, with the CodeGenerator and the HeaderGenerator in a ~good~ state, but unfinished.
Test Plan:
- Run the test cases,
- Compare the diffs generated by the testcases and fix in the code the errors / differences
- Run and compare real kde source with the new and old generators to look for errors
Reviewers: #frameworks, ervin, bport, dfaure
Reviewed By: dfaure
Subscribers: bport, ngraham, kde-frameworks-devel
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D26202
Summary:
The generated classes of kconfig_compiler take a KSharedConfig::Ptr by
value, one possibility would be to make them const & but that is BIC so
instead what we do is just move them to the only place the config is
used so the cheaper move constructor can be used instead of the copy
constructor
Reviewers: ervin, apol
Reviewed By: ervin, apol
Subscribers: kde-frameworks-devel, ervin, apol
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D25061
Summary:
Allows
* projects linking to KConfigCore/Gui to hide deprecated API up to a
given version or silence deprecation warnings after a given version,
using
* -DKCONFIGCORE_DISABLE_DEPRECATED_BEFORE_AND_AT
* -DKCONFIGCORE_NO_DEPRECATED
* -DKCONFIGCORE_DEPRECATED_WARNINGS_SINCE
* -DKCONFIGCORE_NO_DEPRECATED_WARNINGS
* -DKCONFIGGUI_DISABLE_DEPRECATED_BEFORE_AND_AT
* -DKCONFIGGUI_NO_DEPRECATED
* -DKCONFIGGUI_DEPRECATED_WARNINGS_SINCE
* -DKCONFIGGUI_NO_DEPRECATED_WARNINGS
or
* -DKF_DISABLE_DEPRECATED_BEFORE_AND_AT
* -DKF_NO_DEPRECATED
* -DKF_DEPRECATED_WARNINGS_SINCE
* -DKF_NO_DEPRECATED_WARNINGS
* to build KConfigCore/Gui optionally with deprecated API excluded from
the build, using "EXCLUDE_DEPRECATED_BEFORE_AND_AT" cmake argument.
Test Plan:
Builds with EXCLUDE_DEPRECATED_BEFORE_AND_AT set to 0, 4.0.0, 5.0.0,
5.11.0, 5.24.0, 5.39.0, 5.42.0, CURRENT.
Reviewers: #frameworks, mlaurent
Reviewed By: mlaurent
Subscribers: mlaurent, kde-frameworks-devel
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D24496
Summary:
It allows to verify if all the items of the skeleton are in their
default values or if they hold any value deviating from the latest
loaded values from KConfig.
We didn't really need this during the KCModule/QtWidgets time since we
could write KConfigDialogManager just fine without it. But for use with
QML and aiming at having similar magic in KQuickAddons::ConfigModule
such convenience functions will be needed.
Reviewers: #plasma, #frameworks, dfaure, mart
Subscribers: apol, kossebau, davidedmundson, kde-frameworks-devel
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D24494
Summary: We were not adjusting the property name to the getter letter-casing.
Test Plan: See added test, also fixes the issue that made me realize this issue.
Reviewers: #frameworks, davidedmundson
Reviewed By: davidedmundson
Subscribers: ngraham, aacid, kde-frameworks-devel
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D24010
Summary:
In kconf_update, the ctime usage used to be about metadata change time
(buff.st_ctime, before it got ported to the misnamed created()).
I ported it to birthTime, because I think
date of birth is a more useful way to identify a file than
date of permission change which doesn't really matter to us.
But in practice, I can't help but wonder if mtime alone wouldn't be
enough.
For the QStringLiteral("%%1").arg(i) bit, I tested it in tst_qstring,
the first % is left untouched.
Test Plan: make && ctest
Reviewers: mdawson, arichardson, vkrause
Reviewed By: vkrause
Subscribers: pino, arojas, mlaurent, kde-frameworks-devel
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D23815
Summary:
It is very unclear at this point what a valid use case for this feature
would possibly be. The old documentation only mentions $(hostname) as
an example, which can be done with $HOSTNAME instead.
Note that $(...) is still supported in Exec lines of desktop files,
this does not require [$e] anyway (and actually works better without it,
otherwise the $ signs need to be doubled to obey kconfig $e escaping rules...).
Test Plan:
ctest passes; various testcases with $(...) in desktop files,
directory files, and config files, no longer execute commands.
Reviewers: mdawson, aacid, broulik, davidedmundson, kossebau, apol, sitter, security-team
Reviewed By: mdawson, davidedmundson
Subscribers: ZaWertun, rikmills, fvogt, ngraham, kde-frameworks-devel
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D22979
Lets you specify Notifiers= in .kcfg for config entries that should be written with Notify flag,
i.e. announce the change to KConfigWatcher
Differential Revision: https://phabricator.kde.org/D20196
Summary:
When using kconfig_compiler generated sources in projects where the used
file extensions for C++ files are not ".h" and/or ".cpp", the include for
the generated header looks a bit alien to the project, as well as the
generated source file if one looks closer at it.
This code adds new optional flags HeaderExtension & SourceExtension which
can be used to control the file extensions used for the generated files.
Test Plan:
All unit tests and the new test_fileextensions pass, existing projects using
kcfg without & with the new flags build fine.
Reviewers: #frameworks, apol
Reviewed By: apol
Subscribers: apol, kde-frameworks-devel
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D19565
Summary:
commit 6a18528 introduced escaping of bytes >= 127 to ensure that
KConfig files are valid UTF8.
The simplistic approach with a cutoff results in many escaped bytes
where it is not required. Especially non-western configuration files
would have many escapes.
This commit fixes that by only escaping bytes that are not valid UTF8.
BUG: 403557
FIXED-IN: 5.56
Test Plan: ninja && ninja test
Reviewers: dfaure, arichardson, apol, #frameworks, thiago
Subscribers: rapiteanu, kde-frameworks-devel
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D19107
Summary:
of the generated class that has a pointer and raw copy would be bad.
Those generated classes are internal and nobody would probably have this, but being safe never hurts
Reviewers: vkrause
Reviewed By: vkrause
Subscribers: kde-frameworks-devel
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D18136
Summary:
UserBase tells me that KDE configuration files are encoded in UTF-8.
https://userbase.kde.org/KDE_System_Administration/Configuration_Files
In practice some *rc files have bytes outside that encoding. In my home directory I found two files that are not valid UTF-8.
I searched with
find ~/.config/ -name '*rc' -exec file {} +
which gives these exceptions:
akonadiconsolerc: Non-ISO extended-ASCII text, with very long lines
kmail2rc: Non-ISO extended-ASCII text, with very long lines
In kmail2rc, the offending fields are
[AttachmentView]/State
[CollectionFolderView]/HeaderState
Both are QByteArray values saved from QHeaderView::saveState().
In the instance I found, the offending bytes were 0x81 and 0x84.
akonadiconsolerc had way more of these values. All seem related to saving widget state and hence probably QByteArrays.
The written QByteArray values look very strange. The bytes in the non-printable ASCII range are written as \xXX but the values above 127 are written literally.
The encoding is done by KConfigIniBackend::stringToPrintable. It does not currently escape bytes that are larger than or equal to 127.
Reviewers: dfaure, arichardson, apol
Reviewed By: apol
Subscribers: apol, kde-frameworks-devel
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D17651
Summary:
Intention is not to create a registry like system, but to replace
KDElibs4Support::KGlobalSettings and to replace other system settingss
-> some app communication in a more generic way.
writeEntry gains an additional flag Notify which if set, will notify
clients of what has actually changed when we sync.
Rationale to put this into KConfig was so that we could have everything
batched and sychronised to the file sync and to get the fine detailed
exposure of what has actually changed which we don't get with a file
watcher.
Default behaviour remains identical without any broadcast messages.
As it is a new dependency it is purely optional and anything referencing
DBus is not in the public API. Our deployment on platforms without DBus
tend to be standalone applications anyway.
Test Plan: Attached unit test
Reviewers: broulik, dfaure
Reviewed By: broulik, dfaure
Subscribers: dfaure, broulik, zzag, kde-frameworks-devel
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D13034
Summary: They were not being split properly.
Test Plan: Tests pass, including the new one.
Reviewers: #frameworks, dfaure
Reviewed By: dfaure
Subscribers: dfaure, anthonyfieroni, kde-frameworks-devel
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D14162
Summary:
We expand the path of kdeglobals to
~/.qttest/kconfigtests/../kdeglobals
which works during the test, but this cleanup is run both on startup and
after removing ~/.qttest/kconfigtests at which point the expansion
fails.
Test Plan: Ran test, looked at qttest dir. It had cleaned up
Reviewers: broulik
Reviewed By: broulik
Subscribers: kde-frameworks-devel
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D13032
Summary:
Since "Use override" (3985f2a0) kconfig_compiler.cpp
generates usrSave with override instead of Q_DECL_OVERRIDE. This causes
the KConfigCompiler_Test to fail [1], as the reference file of the test
was not updated.
[1]: https://build.kde.org/job/Frameworks%20kconfig%20kf5-qt5%20SUSEQt5.10/32/
Reviewers: #frameworks, mlaurent
Reviewed By: mlaurent
Subscribers: kde-frameworks-devel
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D12892
Summary:
KDesktopFile::sortOrder() returns the value of SortOrder key
as a string whithout parsing it as a list.
But according to Desktop Entry Specification
https://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html
it's type is "string(s)", i.e. the same type as the type of
Actions and MimeType keys, and thus it should be read the same way.
Reviewers: #frameworks, dfaure
Reviewed By: dfaure
Subscribers: dfaure, #frameworks
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D8689
Summary:
The CI has $HOME=/home/jenkins/ with a trailing slash, which leads to
FAIL! : KConfigTest::testPath() Compared values are not the same
Actual (sc3.readPathEntry("homepath", QString())): "/home/jenkins//foo"
Expected (HOMEPATH): "/home/jenkins/foo"
QDir::homePath() is too clean for our purposes, use $HOME on Unix.
Test Plan:
kconfigtest now passes with HOME=/home/dfaure/
Summary: We will be using an external version of it in practice
Reviewers: #frameworks, davidedmundson
Reviewed By: davidedmundson
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D8457
David Redondo
Cyril Rossi
Benjamin Port
Andreas Cord-Landwehr
Ömer Fadıl USTA
Méven Car
Henri Chain
Méven Car
Laurent Montel
Tomaz Canabrava
Albert Astals Cid
Friedrich W. H. Kossebau
Kevin Ottens
Aleix Pol
David Faure
Kai Uwe Broulik
Jos van den Oever
Volker Krause
David Edmundson
Maximiliano Curia
Alexander Volkov