Calling dataChanged() with an invalid QModelIndex() triggered an assertion
inside QConcatenateTablesProxyModel (my Qt is built with assertions):
ASSERT: "from.isValid()" in file $HOME/cheri/qt5/qtbase/src/corelib/itemmodels/qconcatenatetablesproxymodel.cpp, line 623
By passing the appropriate mask we get NET::Notification instead of NET::Override as type
This results in notifications being not added to the model, which makes sense given they are not tasks
Despite our best effors we currently do not match Gedit windows to their desktop file. It manages to evade all of our heuristics.
There is a reliable way to map it and other GTK apps though, the _GTK_APPLICATION_ID window property, which is more or less the same as our desktopFileName property
The logic for handling the active window when it is a transient, added in
https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/509, had
a bug (fixed in 67003f740888fa9d1bcee60cd28ce9a862d2452a).
This reworks the implementation and actually makes the original feature work
(a signal also wasn't properly handled).
BUG: 438222
FIXED-IN: 5.22.1
Needed to make panel Adaptive Transparency work with "Show window thumbnails: always"
Needed to make Minimize All work with "Show window thumbnails: always"
An iconified task/window is in reality hidden. For example, when
`Show Desktop` action is performed, tasks are 'Minimized'. But when
tasks are minimized, they are 'Hidden'.
This property is essential to detect check if a window is truly
iconified or not when the hidden window previews is set to 'Always'.
This isn't always static, espcially in GTK apps where the xproperty is
set later by gmenuproxyodel.
The Appmenu applet already watches for this role changing, but it wasn't
hooked up.
The wayland implementation does not have the same bug.
BUG: 422786
While at it, also remove some unused related includes that are likely remnant from before
this was all done centrally in TaskTools
Differential Revision: https://phabricator.kde.org/D28906
Fixes issues that flew under the radar in D27959, namely:
- Missing KWindowInfo flags
- Returning service name instead of object path
Reviewed-By: kbroulik
Summary:
The tasks model now exposes a window's application menu object path and service name.
No update signals set up for XOrg; not sure what to listen for.
Test Plan:
See that the model has more roles and see that they're wired to the application
menu obiect path and service name on Wayland and XOrg.
Reviewers: #plasma, broulik
Reviewed By: #plasma, broulik
Subscribers: broulik, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D27959
AppData contains a QIcon with pixmap data gathered from KWindowSystem::icon which we can just use.
Only if, for some reason, the icon is really null, try getting it from KWindowSystem on demand.
Differential Revision: https://phabricator.kde.org/D26086
The previous QIcon::name() check wasn't sufficient as it only works with theme icon names (e.g. kate)
but not icons created from an absolute path, e.g. /some/special/icon/location/kate.png.
The latter is usually the case for containerized apps which have a proper application desktop file
installed but their icon in some path within the application image or some container daemon location.
Since we already store the information for whether we had to fall back to using the actual window pixmap,
check for this before trying to serialize icon pixmap data.
Differential Revision: https://phabricator.kde.org/D25762
Summary:
`TaskGroupingProxyModel::requestToggleMaximized` now uses this to
minimize and restore groups of windows while preserving the
stacking order, a frequently user-requested wish.
BUG:368867
Window activation is additionally tracked to implement a new front-
end feature to activate the most recently active window (or fall
through to stacking order otherwise) subsequently.
CCBUG:370258
A Wayland implementation requires the addition of a
`PlasmaWindowManagement::stackingOrder()`, which should be a QList
of PlasmaWindow* in stacking order, along with a change signal. We
discussed this at the Plasma+KWin sprint and I'll code up patches
to KWin and KWayland soon and then implement the new API in here.
Reviewers: #plasma
Subscribers: davidedmundson, pino, anthonyfieroni, ngraham, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D22053
Summary:
KwindowInfo already has the PID, which we use in another case where PID is used.
More importantly I have a patch coming to KWindowSystem that returns the correct PID
for processes inside a PID namespace, but I don't alter the NETProperties.
Reviewers: #plasma, apol, hein
Reviewed By: #plasma, apol, hein
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D22753
Summary:
Includes, among other things:
* A refactoring towards supporting more than one desktop per window,
for an eventual virtual desktops / activities merge
* A scheme for process-internal window ids on Wayland as DND payload
so DND in and to the Pager works in the shell
* Implemented various previously missing behavior in WaylandTasksModel
such as implicit moves of windows to the current desktop on various
actions
* Expanded VirtualDesktopInfo API so the Pager can better abstract
over windowing systems
* Implicit internal sharing of VirtualDesktopInfo since there are many
more instances now
* Various cleanups
Still missing:
* Fixing the VirtualDesktops data role in the grouping proxy
* The protocol doesn't have desktop creation/destruction yet, so some
of the related logic is still missing
* Some FIXME TODOs in the code when I was unhappy with the current
KWayland API
This code is largely untested and subject to change.
Depends on D12820 and relates to T4457.
Reviewers: mart, mvourlakos, davidedmundson
Reviewed By: davidedmundson
Subscribers: alexde, anthonyfieroni, zzag, ngraham, abetts, plasma-devel
Tags: #plasma
Maniphest Tasks: T4457
Differential Revision: https://phabricator.kde.org/D13745
Trace:
Direct leak of 24 byte(s) in 3 object(s) allocated from:
#0 0x544cc0 in operator new(unsigned long) (/home/kfunk/devel/install/kf5/bin/plasmashell+0x544cc0)
#1 0x7fe4f0e82df9 in TaskManager::XWindowTasksModel::Private::windowInfo(unsigned long long) /home/kfunk/devel/src/kf5/plasma-workspace/libtaskmanager/xwindowtasksmodel.cpp:419:25
#2 0x7fe4f0e87e69 in TaskManager::XWindowTasksModel::data(QModelIndex const&, int) const /home/kfunk/devel/src/kf5/plasma-workspace/libtaskmanager/xwindowtasksmodel.cpp:646:38
...
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:
In a log from someone talking about high CPU we can see get multiple X
events for the same window as multiple events, but directly next to each
other. This causes the TaskManager to process changes multiple times
instead of just once which is a waste.
An example is just pressing "enter" in konsole, which will pointlessly
update the title.
This causes problems for expensive app lookup and also QML performs text layouts immediately so any text changes cause quite large CPU usage if done more than 60fps; especially a task text resizing
could result in resizing the entire panel.
Something not relevant in kwin that also monitors these rolls.
This class sits between KWindowSystem and XWindowTasksModel
transparently buffering the changes.
CCBUG: 378010
BUG: 365317
Reviewers: #plasma, hein, broulik
Reviewed By: #plasma, hein, broulik
Subscribers: ngraham, cfeck, broulik, hein, graesslin, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D7481
The window name and user visible name are not used in the app identification heuristic, so a change here cannot result in the icon,
app id, app name, generic name, PID or launcher changing.
Differential Revision: https://phabricator.kde.org/D11096
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:
Windows we can't find an app icon for using the normal means
get the icon used by the windowing system in the Task Manager.
This fallback icon was then not updated when changed on the
window, only occasionally as a side-effect of cache evictions
and model data requests.
This patch notes which windows hit the fallback path, and for
those windows evicts the cache when the icon changes on the
window, causing it to be re-retrieved from the windowing system
as views respond to the dataChanged signal for the decoration
role.
Evicting the entire cache is a little bit costly, but:
- This is a fallback codepath.
- Apps conventionally update title and icon in one go, meaning
the cache is often already getting evicted anyway.
- Icons don't change that often.
BUG:383017
Reviewers: #plasma, davidedmundson
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D7092
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 introduces a TryIgnoreRuntimes key in taskmanagerrulesrc's Settings
group that can be used to list known runtime executables that can be
ignored when trying to identify the application owning a window by the
command line of the associated process.
A concrete example is the Frozen Bubble application. Frozen Bubble
installs a frozen-bubble.desktop with Exec=frozen-bubble, yet its
WM_CLASS is ("perl", "perl") and its command line is as follows:
/usr/bin/perl /usr/bin/frozen-bubble
The existing servicesFromPid() (now split into servicesFromPid() and
servicesFromCmdLine()) does not find the frozen-bubble service because
it works with the leading executable in the command line.
In this patch, TryIgnoreRuntimes is introduced with a default of
"perl". In the new code, after the initial command line matching pass
fails, TryIgnoreRuntimes is checked for whether the leading command
line executable is on the list, and if so, a second command line
matching pass is run with the remainder of the process' command line,
now succeeding.
Note that the approach of "try one more thing" rather than checking
against TryIgnoreRuntimes first is deliberate: The Exec= key in many
.desktop files contains a complete command line prefixed with the
runtime executable. In those cases we don't want to ignore the runtime
executable, or matching would fail.
To complement this, the "perl" WM_CLASS is added to the
MatchCommandLineFirst rc key. Due to the shoddy metadata Frozen
Bubble already ended up in servicesFromPid() regardless, but this
saves some busywork for this WM_CLASS, which can reliably be presumed
bad.
The patch also fixes a small logic error in the match-command-line-
without-arguments block, where the result of a KServiceTypeTrader
query was ignored and immediately overridden by another.
Reviewers: #plasma, davidedmundson, broulik
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D5522
Summary:
We currently match Krita by Name. It's classClass is "krita",
but its DesktopEntryName is org.kde.krita.desktop. However,
Krita also installs numerous additional .desktop entries to
associate more file types by itself, all of which match by
name, and the first one in the list isn't the right one. All
of those extra .desktop files are NoDisplay=true however, so
we can filter them out, which brings the match list down to
the one and only .desktop file we care for.
Reviewers: #plasma, broulik, davidedmundson
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D4928
Summary:
WM_CLASS instance and general classes are checked against StartupWMClass
prior to most rewrite and mapping rules, and prior to the DesktopEntryName
and Name checks.
This matches the fd.o spec more closely and makes Chrome Apps and
LibreOffice work without special mapping rules, which is also a speed
win.
Reviewers: #plasma, davidedmundson, broulik
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D4706
We only matched for the "Default" suffix which is the default profile but this breaks
when having apps installed in different profiles where they get e.g. "Profile_1" suffix.
BUG: 376695
FIXED-IN: 5.9.3
Differential Revision: https://phabricator.kde.org/D4680
Alex Richardson
Nicolas Fella
Volker Krause
Laurent Montel
Alexander Lohnau
Henri Chain
Bharadwaj Raju
Abhijeet Viswa
David Edmundson
Kai Uwe Broulik
Carson Black
Eike Hein
David Faure
Kevin Funk
Christoph Feck
Friedrich W. H. Kossebau