It's properly named now

Other paths that we are watching can end in "icons"
as we are watching subdirs. Make sure to not take the wrong code
path and only do an icon change if one our watched icon dirs
changes.
BUG:463353
FIXED-IN:5.103

Tools aren't renamed to KF6 yet

master is for Qt6-based development now

Qt5 development continues in the 'kf5' branch

master is Qt6 now

Upon KIconTheme construction folders are checked to exist and only
existing ones are used later for lookup of icons.
Now consider that  a new program is installed and it installs its
icon into a  directory inside XDG_DATA_DIRS that before did either not
contain an 'icons' directory at all or there was no folder of
the specific theme  at this specific location.
A typically long running program that  wants to display such icons
like an  application launcher, taskmanager, system monitor  or
window manager won't be able to find these icons.
KDED can watch for 'icons' directories or new theme directories
(subfolders of 'icons' and notify running applications.
KDED seems the correct place to watch for such events, it alreay
does so for a bunch of subfolders of XDG_DATA_DIRS.
BUG:455702
FIXED-IN:5.101

GIT_SILENT

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

GIT_SILENT

In KF6 the concept of service types no longer exists, so don't install the definition

David Redondo authored Jun 23, 2022 and David Faure committed Jun 23, 2022

Currently kded waits 10 seconds before KSycoca is updated.
This is a very long and user noticeable time, for example on a
fresh system without a browser after installing one it will take
that long after the process is finished until the icon appears in
the default Plasma panel.
Historically the timeout was changed in in the before times in
both directions, see kdelibs commits
https://commits.kde.org/unmaintained/kdelibs/f8b972cbc797dca46e63072248cee0daec78f46f
https://commits.kde.org/unmaintained/kdelibs/cc93a95616c8f4d24941dc2ebe1837327153dc3b
https://commits.kde.org/unmaintained/kdelibs/f6ae8d6490f5b0cf18b92337405971018ff568aa
It seems the intention is to batch events together that come in bursts
for example during a system update. A shorter timer will still
achieve the same goal, the wait period starts anew on every change
and subsequent call to QTimer::start. The difference is the delay
between when everything has calmed down to when KSyCoca is updated.

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"