Lift app identification heuristic out of XWindowTasksModel and share it with WaylandTasksModel.
This factors the app identification heuristic out of XWindowTasksModel
and turns it into generic code in TaskTools, producing a URL from a set
of window metadata bits. The key metadata is the 'appId', which is the
classClass part of WM_CLASS on X11 and PlasmaWindow::appId on Wayland -
which KWin sets to the former for XWayland clients. The result is much
improved support for XWayland clients in the Wayland session, with most
X clients now identified correctly.
As a side effect, the Wayland model gains access to the X model's much
superior code for grabbing a suitable icon, with PlasmaWindow::icon now
serving only as a fallback, similar to KWindowSystem::icon in the X
Moving the code to TaskTools also means it now sports nice API docs.
The heuristic has seen some work as well, namely adding two passes that
try to parse the appId as a path to a desktop file, which we've never
seen on X11 but is common on Wayland - this heuristic was previously in
appDataFromAppId, which has been removed here since the shared heuristic
now satisfies this case.
Further, an old codepath handling kcmshell in a special way has been
removed. This is no longer necessary as we have better ways to tell
libtaskmanager about the KCM KService now, such as the .desktop file
window hint on X11 and a reliable appId on Wayland.
This patch also fixes some bugs around app data cache eviction and
telling model clients about data changes when cache eviction happens.
The X model didn't use to evict the cache and refresh when the
taskmanagerrulesrc file was changed at runtime, and the refresh for
sycoca changes didn't refresh the LauncherUrlWithoutIcon role. It does
now, and the Wayland model - which has gained taskmanagerrulesrc support
by way of the shared heuristic - now behaves in the same way.
The combined changes achieve near behavior parity between the X
and Wayland models when it comes to identifying apps by window meta
data, with the only exception being XWayland clients that need to be
identified by the (incorrectly used by the client developer) instance
name part of the WM_CLASS window property, which we can't access (this
case is so rare it's not worth handling at this time).
Reviewers: Plasma, davidedmundson
Differential Revision: https://phabricator.kde.org/D5818