| Age | Commit message (Collapse) | Author |
|---|
|
example didn't compile
|
|
|
|
Otherwise we force consumers to use the config location for state data,
which is what we are trying to avoid.
Task: https://phabricator.kde.org/T12549
|
|
|
|
|
|
* Doxygen sections instead of markdown list items and HTML headers
* More descriptive section titles
* HTML Definition list instead of a wide HTML table for compiler options
* HTML Definition list instead of a markdown item list for data types
* Syntax highlighting for examples
|
|
|
|
Summary:
Allow to write choices such as :
```
<choices>
<choice name="enum_name" value="I can't containt (anything)"></choice>
<choice name="normal_choice"></choice>
</choices>
```
Test Plan: ctest
Reviewers: ervin, bport, crossi, #frameworks
Reviewed By: ervin
Subscribers: ngraham, davidre, kde-frameworks-devel
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D27463
|
|
Differential Revision: https://phabricator.kde.org/D25678
|
|
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
|
|
Reviewers: #frameworks, aacid
Reviewed By: aacid
Subscribers: kde-frameworks-devel
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D17491
|
|
Summary:
it wasn't exactly clear what the inputs for a Color type may be. this is
now explained along with special type descriptions. it isn't perfectly
ideal here since it is a bit hard to find, but better be hard to find
than not documented at all.
from a quick glance at the code indeed anything goes that QColor can
construct from a QString. there is also custom regex code in the compiler
that allows construction from r,g,b,a via the appropriate ctor of qcolor.
Reviewers: broulik
Reviewed By: broulik
Subscribers: broulik, kde-frameworks-devel
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D15576
|
|
SCM_SILENT
|
|
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
|
|
REVIEW: 129188
|
|
|
