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.
If the window never comes, the launcher would remain hidden otherwise;
also, if a startup times out before a window appears, we get an ugly
gap when using launch-in-place behavior (i.e. on Icontasks).
BUG:364612
Summary:
Acts like requestVirtualDesktops only with a QStringList
make runningActivities invokable
Test Plan: See subsequent plasma-desktop review
Reviewers: hein, #plasma
Reviewed By: hein, #plasma
Subscribers: hein, mart, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1814
This is a pretty big behavior change vs. libtm-old, and upon reflection
probably better done early in the 5.8 cycle to find out how deeply users
expect the old behavior.
This reverts commit f542116cc2.
We don't show a startup notification if we already have a matching
window -- however, this test was done against all window tasks, even
if some of them are being filtered out (e.g. by virtual desktop).
Now "do we have a window?" is checked against the filtered window
tasks, so a startup notification for $app is shown even if $app
already has a window on a different desktop.
When a launcher was removed, the cache was invalidated at the time the
top-level proxy removes the row for it. However this happens in
response to rowsAboutToBeRemoved from the source model, at which time
launcherList() still contains the launcher at the row about to be
removed. While invalidating the cache in response to rows being removed
from the top-level proxy is correct (for the case where a window task
shadowing a launcher is removed), to handle a launcher removal we also
need to invalidate it when the launcher list changes.
CCBUG:364537
Summary: clang-check as well cppcheck complains about it
Test Plan: builds
Reviewers: hein, #plasma
Reviewed By: hein, #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1962
This is an unfortunate regression that crept in via 7eff45a98f the
just the other day: Legacy config can have query items other than
iconData in launcher URLs, which also need to be stripped before doing
the equivalence test matching up launcher-backed window tasks with
launcher URLs. Back to venerable launcherUrlsMatch() as originally --
the real speed optimization is in fetching the right role, anyway, and
as it turns out we really can't save that one call to adjusted() as it
was necessary.
BUG:364492
Summary:
Changes the test from "client rect intersects with screen rect"
to "screen that contains the center of the client+deco rect or
screen this point is cloest to".
This is a behavior change also vs. libtaskmanager-old and should
address user bug reports like bug 364280.
BUG:364280
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1925
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
Summary: Second half of the merge of the functionality found in Netrunner's EITM fork.
Reviewers: davidedmundson
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1895