aboutsummaryrefslogtreecommitdiff
path: root/autotests/kconfig_compiler/test_dpointer.cpp.ref
AgeCommit message (Collapse)Author
2022-01-22Make singleton teardown work with Qt6 as wellVolker Krause
In Qt6 the Q_GLOBAL_STATIC will already report to be null while it is in the process of being deleted, we therefore cannot access it anymore from destruction code path as we did before. This problem is hit for example by the Breeze style, making all 6 based widgets applications crash on exit without this.
2020-02-28fix min/max entries with dpointerHenri Chain
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
2020-02-04Add an is<PropertyName>Immutable to know if a property is immutableMéven Car
Summary: Add a utility function is<Parameter>Immutable to access immutability quickly. Generated classes uses them internally to avoid code redundance. Sample: ``` /** Set blocked-by-default */ void setBlockedByDefault( bool v ) { if (v != mBlockedByDefault && !isBlockedByDefaultImmutable() ) { mBlockedByDefault = v; Q_EMIT blockedByDefaultChanged(); } } /** Is blocked-by-default Immutable */ bool isBlockedByDefaultImmutable() { return isImmutable( QStringLiteral( "blockedByDefault" ) ); } ``` ``` /** Set org.kde.ActivityManager.ResourceScoringEnabled */ void setResourceScoringEnabled( bool v ) { if (!isResourceScoringEnabledImmutable() ) mResourceScoringEnabled = v; } /** Is org.kde.ActivityManager.ResourceScoringEnabled Immutable */ bool isResourceScoringEnabledImmutable() { return isImmutable( QStringLiteral( "resourceScoringEnabled" ) ); } ``` Reviewers: ervin, #frameworks, dfaure Reviewed By: ervin Subscribers: dfaure, tcanabrava, kde-frameworks-devel Tags: #frameworks Differential Revision: https://phabricator.kde.org/D26368
2020-01-22Refactor KConfigXTTomaz Canabrava
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
2020-01-17Revert "WIP: Refactor KConfigXT"Tomaz Canabrava
This reverts commit 98c32e29f50465d4d4e16bafdf0491edbfb422b0. This broke kdevelop and kmymoney. I'm workin on the fixes and more unittests for them.
2020-01-16WIP: Refactor KConfigXTTomaz Canabrava
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
2019-10-08Make kconfig_compiler generate ctors with the optional parent argKevin Ottens
Reviewers: #plasma, #frameworks, dfaure, mart, apol Reviewed By: apol Subscribers: kossebau, apol, kde-frameworks-devel Tags: #frameworks Differential Revision: https://phabricator.kde.org/D24490
2019-01-10kconfig_compiler: delete the assignment operator and copy constructorAlbert Astals Cid
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
2018-04-06Fix autotestLaurent Montel
2016-12-16kconfig_compiler: Use nullptr in generated codeKevin Funk
Reviewers: #frameworks, davidedmundson Reviewed By: davidedmundson Differential Revision: https://phabricator.kde.org/D3702
2015-10-30Use QStringLiteral in generated codeMontel Laurent
REVIEW: 125833
2015-08-18Fix unit-tests, expected output changed, so update the tests.Sergio Martins
2014-03-23Add KCoreConfigSkeleton::read() which doesn't call reparseConfiguration.David Faure
Call it from generated singletons, since the constructor creates a KConfig from a filename, which already loads from disk. This removes the need for using DelayedParsing. REVIEW: 116845
2014-01-09Further renaming to kconfig_compiler_kf5Jonathan Riddell
2013-12-18Move kconfig code to the root directory.Jenkins CI