Summary:
Versions of VirtualBox packaged on Neon and Fedora now have
a proper WM_CLASS:
Fedora: WM_CLASS(STRING) = "VirtualBox", "VirtualBox"
Neon: WM_CLASS(STRING) = "Qt-subapplication", "VirtualBox"
And install a matching virtualbox.desktop.
We can therefore drop this rule.
BUG:350468
Side note: The rule should actually still have worked, but
for some reason KServiceTypeTrader refuses to match a .desktop
with 'Exec=VirtualBox %U' when we query for 'VirtualBox', as
extracted from cmdline. I'm talking to dfaure about it.
Reviewers: #plasma, broulik
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D4346
Summary:
It turns out that Chrome under certain conditions will change its
window metadata as it quits, causing a race we sometimes lose, failing
to reveal the associated launcher because we can no longer match it
to the window at window closing time. Instead we are now forced to
re-check all launchers after the window is gone. As a speed optimi-
zation we only consider top-level windows (and startups) as being in
a group implies matching siblings.
In addition this refactoring eliminates a use of Qt::QueuedConnection
that allowed for an unpredictable event loop spin inbetween things.
BUG:365617
Reviewers: davidedmundson
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D3950
Summary:
As this happens the screen filtering higher up in the proxy chain
culimating in TasksModel needs to be re-executed, as it compares
ScreenGeometry against a property value set on the model. Without
this update, tasks may disappear from views using TasksModel.
Mapping the trigger conditions to affected rows is deliberately
maximally coarse; see implementation comment in code.
BUG:373075
Reviewers: #plasma, davidedmundson
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D3628
Summary:
This adds a new data role "ChildCount" to AbstractTasksModel and
implements it in TaskGroupingProxyModel.
The purpose of this data role is as a means of signalling to a Qt
Quick delegate for a top-level row that a property of the item -
namely the number of children it has - has changed. Qt Quick's poor
support for tree models makes the existing way of signaling this
(rowsInserted) prohibitive to use.
The Task Manager applet needs this info because it's in charge of
telling the window manager about the screen coordinates of window
delegates (through support code in this library). When a window is
directly added to an existing group, there is no new delegate
created, nor does the existing delegate change position. An
increase of ChildCount will be used in this case to decide to
publish delegate geo for the new window.
CCBUG:372699
Reviewers: #plasma, davidedmundson
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D3482
Depending on the distribution, Chromium identifies itself as "chromium" or "chromium-browser". Account for this.
CHANGELOG: Chromium WebApp windows are no longer treated as Chromium browser windows in task manager
Differential Revision: https://phabricator.kde.org/D3450
Google Chrome needlessly changed its window class class to Google-chrome
(was google-chrome previously) breaking our launcher mapping.
BUG: 372211
FIXED-IN: 5.8.4
Differential Revision: https://phabricator.kde.org/D3308
If our regular expression matching found a service but there was also some non-regular expression rule in the file,
it would overwrite a potentially valid service match.
CCBUG: 372211
Differential Revision: https://phabricator.kde.org/D3309
Summary:
Utility windows (NET::Utility/_NET_WM_WINDOW_TYPE_UTILITY) should
not be on the Task Manager, but they should be on the Pager. This
patch achieves this by evaluating the window type in the
AbstractTasksModel::SkipTaskBar data role.
I considered the alternative approach of making a new
AbstractTasksModel::IsUtilityWindow (or similar) data role and
adding a pass to evaluate it to TaskFilterProxyModel, then
configuring the filter models in TasksModel and the Pager backend
differently. But this is not very extensible. Then I realized that
AbstractTasksModel data roles do not and should not reflect X11
idioms anyway; the point of the library is to abstract for the
purpose of UI, and what XWindowTasksModel considers "SkipTaskBar"
is really an implementation detail. This makes all the more sense
considering on Wayland we have no notion of window types (beyond
"popup") yet, and don't quite now how it's going to evolve.
Various API docstrings have been changed to better reflect that
the meaning of the data role doesn't map to anything specific in
the tasks.
BUG:368956
Reviewers: #plasma, davidedmundson, broulik
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D2807
Summary:
This makes grouping work for apps we can't find on the system and
can't produce a launcher URL for, such as wine clients. Any better
app will use our superior codepath, the wonky ones like wine then
get left to making sure their WM_CLASS Class makes sense as per the
ICCCM spec.
Of course this doesn't work for XWayland clients on Wayland though.
BUG:368078
Also nixes an obsolete FIXME and adds a small check to avoid
producing launcher URLs that are only the window icon pixmap
query element.
Reviewers: #plasma, davidedmundson, broulik
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D2804
Summary:
Tasks which demand attention usually bypass the filters by activity
and desktop, i.e. the Task Manager will show a window that's
demanding attention even when filtering is enabled and we're on a
different activity or desktop.
This behavior is however not suitable for the Pager, which shouldn't
show windows demanding attention on all workspace delegates. This
patch adds a prop that allows the Pager to disable the filter bypass.
Reviewers: #plasma, davidedmundson
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D2802
Summary: For use by Desktop Pagers using libtaskmanager.
Reviewers: #plasma, davidedmundson
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D2675
Summary: For use by desktop pagers using libtaskmanager.
Reviewers: #plasma, davidedmundson
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D2674
Summary:
Create a subclass of AbstractTasksModelIface which proxies the call to
the source model.
All proxy models can then re-use this rather than duplicating the code
Test Plan: Clicked some things
Reviewers: #plasma, hein
Reviewed By: #plasma, hein
Subscribers: hein, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D2381
Summary:
This makes TaskFilterProxyModel useful for filtering a source tasks
model (e.g. WindowTasksModel) without implicitly filtering out tasks
that don't want to be shown on a 'task bar'.
Reviewers: #plasma, mart, davidedmundson
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D2380
Summary:
This introduces a new WindowTasksModel which is a QIdentityProxyModel
around an instance of either WaylandTasksModel or XWindowsTasksModel.
This arbitration was previously done directly in TasksModel, along with
refcounting to share a single window tasks sub-model between TasksModel
instances. Factoring out both of these things has two goals:
- It allows users of libtaskmanager which are solely interested in
window data (e.g. the Pager) to skip the unnecessary complexity
of TasksModel, while still sharing the windowing monitoring with
users of TasksModel.
- TasksModel becomes fully free of windowing system-specific code
and calls to KWindowSystem (to query the platform), making its
code a little cleaner.
The downside is another layer of indirection (the QIdentityProxyModel),
but the upside is clear: The Pager wants to share window data and
window monitoring with the Task Manager, but is not interested in
startup notifications, does its own sorting (using the window stacking
order), does not need grouping and has different filtering needs.
The Pager backend will use QSortFilterProxyModel around WindowTasksModel
to mix in its own data and sort by stacking order.
Reviewers: #plasma, mart, davidedmundson
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D2379
Summary:
Previously the launcher tasks model was always instanciated; with
this change it's only done once a launcher list gets set or a
request to add a launcher happens. This avoids an unnecessary model
in TasksModel instances that will never store any launchers (e.g.
in the Window List applet).
Reviewers: #plasma, davidedmundson
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D2378
Summary:
Reduces code duplication and we always opperate on cached value, that
is the platform is only checked once in application life cycle.
Reviewers: #plasma, hein
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D2342
Summary:
We've had bad experiences with state() in a plasma-framework testcase
and this is more readable regardless.
Reviewers: #plasma, graesslin
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D2181
In practice the parent will no longer jump around when a group is dissolved
by dropping the member count to 1 by deleting the 'lead' entry (the source
index the parent maps to). When doing this from the group's tooltip, the
delegate would run amok as a result.
BUG:365173
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
TaskGroupingProxyModel appends; the proxy may sort differently
(e.g. alphabetically by default). The win id list was returned
in TGPM sort order, which meant the tooltips had the thumbnails
in the wrong order, and clicking them would activate the wrong
window.
BUG:365181
Fixes a nasty bug causing two TasksModel instances to interfere
with each other.
BUG:365011
Also removes an assumption that the launcher list will pass
through LauncherTasksModel unharmed -- if launchers become
activity-silo'd, that might not be the case any longer.
- Use appsMatch() consistently. Some blocks were still repeating its
business logic redundantly.
- Now that we have the ordering worked out, updateLauncherCount can just
count after all the filtering is done for an additional speedup. We
can also avoid calling it for every about-to-be-removed row.
This also fixes that updateLauncherCount wasn't considering appid
matches (it was only looking at URLs), whereas filterAcceptsRow
worked like appsMatch() did, causing a wrong launcherCount in the
edge case of the URLs for a stored launcher and a running window
not matching, but the app id matching.
- Some more sanity checks in startup notification comparisons.
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.
Eike Hein
David Rosca
Kai Uwe Broulik
Ivan Čukić
Aleix Pol Gonzalez
Christophe Giboudeaux
Harald Sitter
David Edmundson
Martin Gräßlin
Marco Martin