Summary:
Some apps initially show their window with bogus/useless window
metadata and then update to useful metadata during early startup.
For example, LibreOffice sets WM_CLASS to soffice/Soffice and
then updates to libreoffice-writer/libreoffice. This leads to
a poor user experience on particular the Icons-only Task Manager,
but also the regular Task Manager depending on settings.
Depending on its configuration (and Icons-only Task Manager is
a particular set of configuration options, as far as the model
is concerned), TasksModel will try to sort a new window task
adjacent to its launcher task. The appearance of a new window
task also causes matching (in terms of identification) launcher
or startup tasks to be filtered out. To the user, this forms a
lifecycle of the launcher being replaced by the window in-place
(and a startup state inbetween, optionally but by default).
Prior to this patch, this sorting decision was only done once,
when a new window enters the source model stack. This meant the
LibreOffice window would initially be sorted into the "wrong"
spot (the bogus metadata doesn't allow us to relate it to its
launcher) and then, following the metadata change, stick to the
wrong position.
Simply changing the code to sort things again on any metadata
change would not have been good enough: Metadata changes can
occur at any time, and things should not just move around on
the user - this sort mode is called "Manual" for a reason. Also,
the visual result would still be poor: The window would initially
appear at the wrong position, then move to the right one a bit
later.
This patch takes the following approach:
* It adds a new config key to taskmanagerrulesrc for listing
ids of matching tasks to completely hide, and of course the
code needed to implement this.
* It adds LibreOffice' bogus initial metadata to this key, so
the tasks is initially hidden.
* The sort code skips over hidden window tasks in the sort
insert queue instead of moving them. The queue is marked as
stale then, and cleared on unrelated windowing system changes.
* It resorts when tasks are unhidden (i.e. once the metadata
update has occured and the task no longer matches the above
config key).
The visual result is that the startup notification on the
launcher spins a little bit longer than before, even though the
window has already appeared (although LO lags in filling in its
contents anyway), and then morphs into the window task
representation once the client has completed the window metadata
change. This happens in such a short order as to be more or less
imperceptible.
If startup notifications are turned off it's broadly the same,
minus the spinning.
BUG:396871
Reviewers: davidedmundson, broulik, ngraham
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D15410
Summary:
The overall mission of TaskTools::windowUrlFromMetadata is to use
various pieces of metadata to run KServiceTypeTrader queries and
get a list of matching services. Sometimes this will find more than
one service. So far we simply used whatever KServiceTypeTrader
returned first, but in some cases we can and should do better. The
included lengthy code comment names an example case.
In concert with D13058, this allows both the Linux-native and Wine-
installed (S|s)team.desktop files to coexist and their windows be
correctly mapped to the relevant .desktop file, by exploiting that
by their nature each case ends up with a different KService::menuId()
(that this is useful for differentiation is why the menuId differs,
after all).
This change looks like it introduces disgusting complexity at first,
but in some sense, trying to pick the most match-y out of the found
services instead of just randomly picking the first one makes sense.
Reviewers: broulik, davidedmundson
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D13073
Summary:
After we improved our StartupWMClass handling we worked with Wine
in https://bugs.winehq.org/show_bug.cgi?id=32699 to get them to add
StartupWMClass=foo.exe keys to the .desktop files they generate,
since they have foo.exe in WM_CLASS.
This old rule short-circuits the StartupWMClass handling prevented
this from actually working on our side.
BUG:393787
Reviewers: broulik, davidedmundson
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D13058
Summary:
In any place we look up a KService, check if it has a menuId,
and then generate KAStats-style applications: URL with it. Also
learn how to handle applications: URLs.
This was requested by Kai in D7203. His patch makes Kate
dynamically add its sessions as jump list actions to a copy of its
.desktop file in $HOME. As the library would generate the absolute
path to a .desktop file e.g. in /usr as launcher URL before, the
TM applet would ignore the overriding copy in $HOME and the actions
wouldn't be found.
This patch won't rewrite existing config, but LauncherTasksModel
will resolve the absolute path to the applications: URL as it goes
through TaskTools, and then return that. The window and startup
tasks models produce those URLs, too, so things match up. Newly-
added launchers will then store the applications: URL in config
directly.
Moving away from storing absolute paths when we can is also nice
in case there is a $HOME .desktop file at the time a launcher is
added which later gets deleted. Using the new storage format, we
will now fall back to a system file instead.
Note the conservative approach taken: We only generate an
applications: URL when the service returns something for menuId().
We don't use KService::storageId() here, which can fall back to
KService::entryPath() - in this case we're better off just using
the absolute path we already have. We still use storageId() when
generating the applications: URL for KAStats db insertions, as
that is more liberal (and matches Kicker).
It makes sense to look at the Kicker backend code to see if should
store applications: URLs (which it already produces to insert into
KAStats) as well.
This will need a subsequent patch to the Task Manager applet to
handle applications: URLs there in code that consumes launcher URLs
to parse things out of .desktop files.
Contains other minor cleanup and fixes, such as porting the
LauncherTasksModel to use TaskTools::runApp (which now understands
preferred: URLs as well), a fix for a small logic error there (the
&& before the !isApplication should have been ||, now moot), and
not needlessly opening and parsing a .desktop file in
TaskTools::appDataFromUrl.
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D7561
Summary:
Also better sanity-checking of found services being app services
all around.
I'm not particularly happy about adding more X11 code outside of
XWindowTasksModel, but it means greater code reuse (in something that
has experienced unwelcome drift before) and there's a precedent in
LauncherTasksModel.
Reviewers: #plasma, broulik
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D6358
Summary:
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
model.
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).
Depends on D5747, D5755.
Reviewers: #plasma, davidedmundson
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D5818
Summary:
This adds support for app ids which are absolute paths to .desktop
files to WaylandTasksModel, matching the heuristic in XWindowsTasksModel.
Behavior between the two models is made more similar in various ways,
such as matching codepaths for generating the ids inserted into the
KActivities database in requestNewInstance/requestOpenUrls (also the
X11 model was missing the notifyAccessed calls) and producing launcher
URLs.
Icons are still left to KWin however, instead of reading them from
KService (which is what KWin does in any case on Wayland) or from the
.desktop file. The latter might make sense, but to avoid duplicated
code would then best be done in KWin.
Reviewers: #plasma, graesslin, broulik
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D3292
Summary:
Avoids problems stemming from libtaskmanager and plasma-framework's
AppletInterface::screen numbering screens differently (QScreen order
vs. who knows what).
CCBUG:365246
Reviewers: #plasma, graesslin, mart
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D2143
I doubt anybody actually had a Task Manager launcher for
their window manager pinned -ever-, and there was a broken
hardcoded fallback on "kwin" in there.
Summary:
Makes the API more complex, but it's worth it as it allows
knowledgable users to opt into avoding costly work and/or
data copies in very common use cases.
Significantly speeds up a lot of work in the models in the
presence of X apps that can't be identified and fall back to
the window icon.
Based on profiling by David.
Reviewers: dfaure, davidedmundson
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1920
Summary:
Makes the API more complex, but it's worth it as it allows
knowledgable users to opt into avoding costly work and/or
data copies in very common use cases.
Significantly speeds up a lot of work in the models in the
presence of X apps that can't be identified and fall back to
the window icon.
Based on profiling by David.
Reviewers: dfaure, davidedmundson
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1920
Eike Hein
Yuri Chornoivan
Christoph Feck
Friedrich W. H. Kossebau
Kai Uwe Broulik