GitLab

With KDevPlatform no longer a stand-alone product, but effectively
only an internal architecture platform of KDevelop, the About data
and the About KDevPlatform dialog no longer make sense

Any author information is merged with the one of the KDevelop app,
which it already almost was a subset of.

Only unload plugins after the DUChain shutdown to prevent infinite loop due to non-loaded factories for types

Passing in a plain int gets localized integer text rendering with
e.g. thousand separator (2.019), which is not what we want here.

By feedback of localization teams the original year span is used, and
not mapped into local calendar systems at least by the active teams,
so just passing in a plain string is fine for now.
Cmp. https://marc.info/?l=kde-i18n-doc&m=157238863619132&w=2

BUG:413390
FIXED-IN:5.4.4

When KDevelop starts up, we will quite early receive the background
parse requests for the last opened documents in the session. These
then often get added to the background parser (BP) before the project
controller is fully initialized - i.e. before any project was even
tried to be loaded. This means the m_loadingProjects safety guard in
the BP does not kick in and we create parse jobs with "broken"
environments, i.e. missing include paths and defines for kdev-clang.
If, and only if, the document has been modified since the last time
KDevelop was started, we would actually parse the document with the
broken environment, leading to flickering when we show the result
for the broken environment before reparsing it after the project gets
opened with the correct environment. Additionally, this of course
adds useless load to the startup phase and frees up resources better
spent elsewhere at this point.

Note that since the project controller itself delays its
initialization via the eventloop, we have to add a new signal to
ensure we resume the background parser only once we have tried to
open all previous projects, such that the m_loadingProjects safety
guard in the BP can kick in properly.

This is not fully integration-tested, as it's pretty complicated
to do so. Rather, we only test the individual parts automatically.
The full integration test was done manually via:

- create kdev session and open some project
- open a file in that project
- close session with file still opened
- touch file on disk to force reload on next startup
- restart kdevelop session
- check visually and via CLI output whether file gets reparsed twice,
  i.e. before the project was loaded and afterwards

This patch series ensures it only gets reparsed once after the project
finished importing.

Subscribers: kdevelop-devel

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

(Without the transformations to std::move(...))

(cherry picked from commit f5b25083)

(Without the transformations to std::move(...))