GitLab

this frees the internal per-thread inotify instance used to watch
database changes meaning runner applications no longer claim N inotify
instances (N=size of threadweaver pool).
the database is still reloaded by ksyscoca internally if it finds the
backing file has changed.

CCBUG: 423818

kcms are handy but not nearly as handy as an actual application. this is
particular notable with the test case where the user could type 'virt'
but that wouldn't have pushed virtualization software to the top but kcms
since kcms are kde things so they always get a .09 bump to
relevance.

the revised scoring excludes kcms from the bump and further reduces the
relvance by the tiniest fraction. this results in all applications that
match at least as well as the KCM to outscore the KCM

Summary:
build the runner itself in a static lib we can use for testing and then
link that into a module lib together with the factory entry point to
compose the final lib for installation

means servicesrunner.cpp is now only built once, whereas before it was
built twice through 100% duplicative targets

Test Plan: test still passes, installing and restarting krunner still yields working service searches

Reviewers: broulik, davidedmundson

Reviewed By: davidedmundson

Subscribers: plasma-devel

Tags: #plasma

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

Summary:
- be more consty (and don't risk detatching containers)
- init members
- don't ql1s to qstring
- use auto when newing an object

Test Plan: test passes

Reviewers: broulik

Reviewed By: broulik

Subscribers: plasma-devel

Tags: #plasma

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

Summary:
after the recent set of changes to disqualification we ended up with a bit
too lax disqualification. if we saw the exec OR the storageid we'd
hence forth disqualify a service with either of them being equal.

in case of system settings this causes a match problem. systemsettings
has two desktop files one !KDE and one OnlyKDE they are however exactly
the same except for a different name and storageid. as a result if the !KDE
one is encountered first it will be disqualified on account of
noDisplay=true and marked as seen. when the OnlyKDE systemsettings is then
iterated it will already have the Exec entry in the seen list and be
disqualified on account of that.

to prevent this type of confusion make it a requirement to match both
storageid AND exec before disqualifying.

it may actually be suitable to drop the exec altogether. say I copy firefox
into the user local applications dir and set it NoDisplay=true but change
the exec. this would still lead to the system-wide firefox being found as
it is not getting disqualified. long story short: maybe we should
disqualify services solely on the storageid?

Test Plan:
- new autotest case
- fails without changes
- passes with changes

Reviewers: broulik

Reviewed By: broulik

Subscribers: plasma-devel

Tags: #plasma

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

Summary:
- make sure that chrome apps have lower relevance than chrome itself
- makes sure that konsole has higher relevance than yakuake (latter
  only references onsole in the comment entry)

Test Plan:
- it passes and at a glance doesn't seem to break my production sycoca

Would be cool if @dfaure could take a look at the ksycoca setup to make sure the test doesn't negatively impact the production cache.

Reviewers: broulik, dfaure

Reviewed By: dfaure

Subscribers: dfaure, plasma-devel

Tags: #plasma

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