Summary:
Previously we updated the prop after checking for
AbstractTasksModel::IsDemandingAttention on window closure, but
as the window is gone, we can't actually get state for it anymore,
so we always need to update.
To make up for it, this patch also optimizes the prop updates to occur
only once per insert/remove batch - this is a bit academic because
the source models currently only insert single rows at a time, but
it's good hygiene.
BUG:378254
Reviewers: #plasma, mart
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D5261
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:
The new activity-aware implementation of
LauncherTasksModel::setLauncherList() would only accept the passed list
when it changed any activities associations, not when the order changed.
This would effectively turn TasksModel::move involving launcher tasks
into a no-op.
Rearranging launchers works like this:
1. A client calls TasksModel::move one or many times. TasksModel::move
updates TasksModel's internal sort mapping and implements it, causing
a visible order change in any views.
2. When it is done calling move(), the client calls
TasksModel::syncLaunchers. TasksModel::syncLaunchers calls
LauncherTasksModel::setLauncherList with a new list derived from
its sort mapping, and updates its sort mapping in expectation of
row indices changing in the launcher tasks source model.
Due to the above bug, the sort mapping would be adjusted in expectation
of changes the launcher tasks model would not actually do, appearing to
undo the moves the next time a view is updated from source data.
CCMAIL:ivan.cukic@kde.org
Reviewers: #plasma, davidedmundson, mart
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D4749
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
Summary:
What happens:
* Activity switch calls invalidateFilter on TaskFilterProxyModel,
which may remove rows in response.
* Up the proxy chain, TasksModel may ask LauncherTasksModel to
emit dataChanged for its contents in response to the row removal,
to cause its own filtering to re-evaluate the launchers for the
life cycle logic.
* This can cause TFPM to do more filtering before invalidateFilter
has actually returned, causing trip-ups such as duplicated rows
in the proxy.
* Eventually the corrupted maps cause a memory corruption crash.
This patch changes step 2 to "find the launchers in the TFPM (the
direct source model) and ask for a dataChanged for each". This
costs us a loop and accesses to IsLauncher, but on the other hand
fixes the crash and avoids a lot of filtering and mapping work
between LTM and up to and including TFPM. It's also just better
code to ask for the dataChanged only from the model we need it
from.
BUG:376055
Reviewers: #plasma, davidedmundson
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D4631
Summary:
Alphabetical sorting currently compares a concatenation of
"AppName" (determined by heuristic) and Qt::DisplayRole (usually
the window title) using QString::localeAwareSort. This reflects
that the motivation behind alphabetical sorting is generally to
keep windows belonging to the same app grouped together and then
order those groups alphabetically.
The current code achieves this, but the particulars turn out to
negatively impact users of multi-windowed apps that frequently
change window titles in ways that impact sorting, particularly
tabbed web browsers. Switching between tabs may change the order
of browser windows on the Task Manager. Multiple instances of
feedback suggest this is jarring and unexpected, despite
technically being alphabetical.
This patch changes behavior as follows:
1. Instead of comparing "<App Name><DisplayRole>" it will try to only
compare "<App Name>", falling back to "<DisplayRole>" if the app
name can't be determined.
2. If two tasks compare to equal in the above, it will fall back to
source model row order, i.e. creation/append sorting.
This still achieves the primary goal laid out above while
keeping the sort order within an app "group" stable when using
alphabetical sorting.
BUG:373698
An alternative means to achive this behavior would be via existing
Task Manager settings. To wit:
1. Enable grouping
2. Disable group popups, so groups are instead maintained inline
on the widget
I'm actually considering suggesting the above (plus changing
sorting to Manual) as new default settings for 5.10 - but in
the meantime it still makes sense to tune the alphabetical
sorting mode in this way, and put the improved behavior into
5.8 and 5.9 to address user feedback earlier.
Reviewers: #plasma, davidedmundson
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D4469
Summary:
syncLaunchers() is called after drag operations end to write the order
of launchers in the all-capping TasksModel to the LauncherTaskModel
source model. The per-activity launcher pinning work recently broke
this by changing the model that's looped over.
Reviewers: #plasma, ivan, davidedmundson
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D4608
Summary:
Hitting again a bug where switching desktops shows a delay of several seconds
before the taskbar updates, I noticed that this code path was called 81
times in 7 seconds (!) for kmail (maybe because I start it from cmdline
rather than via a .desktop file).
After the 4 slow calls to KWindowSystem::icon it seems definitely worth
it to cache the result.
Overall the main performance bug is still there though, switching
desktops is still slow, but now all backtraces show QML triggered
by model/view dataChanged signals, no idea yet, other than hoping
for the pending QSFPM patches to help with this (no need to re-sort
when the dataChanged roles are unrelated to the roles used for sorting).
Reviewers: hein
Reviewed By: hein
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D4600
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:
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:
This makes the AdditionalRoles enum available to Qt Quick. Useful for
calling data() TasksModel from inside QML, which uses AbstractTasksModel
roles but doesn't actually inherit from AbstractTasksModel.
The reason TasksModel doesn't inherit from AbstractTasksModel is
because it inherits from QSortFilterProxyModel, and it doesn't fly
to multiple-inherit from two QObject-derived classes. This is also
why AdditionalRoles can't be moved to AbstractTasksModelIface easily.
The VDG is working on tooltip changes that require this.
Reviewers: #plasma, davidedmundson, subdiff
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D3641
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
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:
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:
The former depends on https://git.reviewboard.kde.org/r/129327/
The latter is a thematically related cleanup I did along the way.
The strange original code was probably to handle the NULL_UUID, but
TaskFilterProxyModel (where this data role becomes relevant)
developed the ability to do this since.
Reviewers: #plasma, graesslin
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D3262
Summary:
Currently kactivitymanagerd is loaded halfway through this test, which
has the net result of just breaking.
The test doesn't need it and still passes without it.
Test Plan:
Ran the unit test that's been failing on CI for ages.
It used to fail locally (if run in a new session, see my email on
plasma-devel)
now it passes.
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D3229
- The URL in the configuration file now contains also the list
of activities it should be shown in
- The configuration format is backwards compatible
- Added API to differentiate between the shown launchers (for
the current activity), and all configured launchers
- Supports reordering of the launchers
Testing: It needs the ivan/per-activity-launchers branch of
plasma-workspace because of the API changes
Eike Hein
Kai Uwe Broulik
David Faure
David Rosca
David Edmundson
Ivan Čukić
Aleix Pol Gonzalez