| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
Summary:
Instead of having an odd fake of it. Will help some required
refactorings and already showed some issues, fixed by this patch,
namely:
- don't use string(regex replace) to extract a string from another
string. in case it doesn't match it will offer the whole content which
is never what we want.
- messages(ERROR), the correct parameter is FATAL_ERROR, cmake
understands "ERROR" as mere output string
- turn the macro into a function, otherwise 2 calls in the same
subdirectory are dangerous.
CCBUG: 371562
Test Plan: tests still pass, projects that use the macro still build
Reviewers: #frameworks, dfaure
Reviewed By: dfaure
Subscribers: dfaure
Differential Revision: https://phabricator.kde.org/D3178
|
|
In applications translations can be looked up in the globally set
translation domain, but in libraries it is necessary to link every
i18n call to the library's own translation domain. A new code
generation option TranslationDomain= is added to enable this.
It has effect only if TranslationSystem=kde is set.
Added unit tests to check generated translation calls.
CHANGELOG: New code generation option TranslationDomain=, for use with TranslationSystem=kde; normally needed in libraries.
REVIEW: 123872
|
|
|
|
It adds a configuration setting that makes it possible to generate
Q_PROPERTY instances out of each variable exposed by the configuration
class.
Especially useful when it comes to exposing these classes to QtQuick
interfaces.
REVIEW: 123367
CHANGELOG: Generate QML-proof classes using the kconfigcompiler
|
|
Add new variable to specify it in *.kcfgc : "CategoryLoggingName"
CHANGELOG: Allow to generate file with qloggingcategories support.
REVIEW: 122931
|
|
This reverts commit 88c9a9664e99b639df4cde2be22dbe44df228879.
|
|
|
|
The MOC files for generated output from kconfig_compiler are not automatically
generated. Re-add the code that does this, fixing the build.
I'm assuming this isn't an issue on Windows, as I don't have any machines to
test on. Please let me know if this isn't the case.
CC: arichardson.kde@gmail.com
|
|
We have to generate the files in the same directory as the test executables
otherwise QFINDTESTDATA will fail
|
|
This also fixes running 'nmake test' on Windows.
|
|
Just because the executable has the "_kf5" suffix, that does not mean
the target should have it. This is ugly API, and will be unnecessary
porting effort for KF6.
REVIEW: 116995
|
|
Previously the classes generated by kconfig_compiler would only emit
the defined signals when using the setters provided by that class.
However, when using e.g. KConfigDialog which uses
KConfigSkeletonItem::setProperty() to change the items no signal was
generated.
This patch fixes this by using a wrapper KConfigSkeletonItem
subclass that calls a private itemChanged() method in the generated
class which updates the set of changed properties. As soon as the item
is saved (usrWriteConfig() in the generated class is called) the signal
will be emitted
REVIEW: 115635
REVIEW: 115634
|
|
|
|
|
