Summary: Following D27059, add `parentGroupName` attribute to `group` element to generate kconfig settings with subgroups Reviewers: ervin, dfaure, #frameworks, meven Reviewed By: ervin, meven Subscribers: apol, meven, kde-frameworks-devel Tags: #frameworks Differential Revision: https://phabricator.kde.org/D27133
Summary: D27497 was causing cases with dpointer + min/max to fail Specifically, this okular build: https://build.kde.org/job/Applications/job/okular/job/kf5-qt5 SUSEQt5.12/175/console Test Plan: Added min/max to dpointer autotest Reviewers: meven, ervin Subscribers: kde-frameworks-devel, aacid Tags: #frameworks Differential Revision: https://phabricator.kde.org/D27717
Summary: See https://phabricator.kde.org/D27497#618156 Test Plan: ctest Reviewers: hchain, ervin, bport, crossi, #frameworks Reviewed By: hchain Subscribers: kde-frameworks-devel Tags: #frameworks Differential Revision: https://phabricator.kde.org/D27672
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
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: 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
This reverts commit cd4e6504dfbdface00037625f0cedda511e6d839. As suggested by Martin on release-team@kde.org, given that it breaks SC.
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