kconfig.git/src/kconf_update, branch v5.74.0-rc1

autotests: stop polluting /tmp with kconf_update.* temp files

2020-08-30T21:48:38+00:00

kconf_update: test the return value of QTemporaryFile::open() for good measure

2020-08-30T21:48:10+00:00

Use KF-standardized Qt logging categories

2020-07-13T00:27:38+00:00

See https://community.kde.org/Frameworks/Frameworks_Logging_Policy

Use camelcase include. (scripted)

2020-07-07T18:59:51+00:00

KConfig: Convert to SPDX license statements

2020-03-22T11:46:41+00:00

Summary:
Convert license headers to SPDX statements and add
license files as required by REUSE specification.

Reviewers: cgiboudeaux

Reviewed By: cgiboudeaux

Subscribers: ognarb, cgiboudeaux, kde-frameworks-devel

Tags: #frameworks

Maniphest Tasks: T11550

Differential Revision: https://phabricator.kde.org/D27601

Use ecm_qt_install_logging_categories over manual categories file

2020-02-12T17:05:39+00:00

Remove endl at the end of qdebug

2020-01-03T06:28:43+00:00

[KConfig] port away from deprecated methods in Qt 5.14

2019-09-17T16:27:06+00:00

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

String code optimization: use QLatin1String/QChar overload for string concat

2019-08-24T07:07:32+00:00

GIT_SILENT

point readme to the wiki page

2019-03-26T11:57:41+00:00

Summary:
the wiki page says the readme is duplicated into the wiki.

so, what we end up with is either

- they end up out of sync
- someone gets real angry because the wiki needs format markup while the
  readme must not have markup
- someone doesn't get angry and simply copies either markup or nomarkup to
  the respectively unsuitable target

it's an unsustainable situation... so instead let's point the readme to
the wiki and consider that the place where the documentation is maintained

Subscribers: kde-frameworks-devel

Tags: #frameworks

Differential Revision: https://phabricator.kde.org/D19779