Summary:
Due to not passing `parent` to QAIM::index(), we were moving top-level
indices in the map instead. This meant the sort map would become out of
sync with the row move, and to the user it would look like both the
group children and unrelated top-level entries moved.
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D15550
Summary:
Turns out c8358c203f only worked accidentally. We can't do this
via filterModel->mapFromSource, because in a lambda connected to
its source model's rowsInserted signal, the proxy hasn't seen that
row yet.
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D15462
Summary:
LibreOffice reuses the same main window for both its start center and
sub-apps like Writer launched from it, changing the window metadata on
the fly. This ensures we hide e.g. a launcher for Writer when picking
it in the LO start center.
Reviewers: broulik
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D15458
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 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
Summary:
TaskGroupingProxyModel used to return QVariant() as the
AbstractTasksModel::VirtualDesktop role for task groups,
resulting in TasksModel to sort task groups indiscrimi-
nately at the front of the list. In this patch, it instead
returns the lowest virtual desktop found among the children.
BUG:384747
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D11257
Summary: Used in the minimizeAll plasmoid (see D10019)
Test Plan: Used in applet
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D11059
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:
The business logic was using the resolved URL in lookups in
internal data structures, instead of the internal key it
previously established equivalence to. This could lead to
junk in internal maps and unnecessarily emitted model changes.
This also improves the unit test not to require apps to be
installed, fixing the CI failure over missing Dolphin.
Reviewers: #plasma, kossebau
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D10253
Summary:
This introduces the use of QQmlParserStatus to delay populating
the model until all properties have been set, to avoid delegate
churn.
TasksModel is also meant to be used by C++. There's no good way
to determine whether an object is being instanciated by QML
during construction time, therefore this patch also introduces a
delay in initial population of the model after construction via
a single-shot timer. At the time the slot is invoked we know if
we're used by QML (because QQmlParserStatus::classBegin has
either been called or not by then) so we can decide to populate
or wait more for QQmlParserStatus::componentComplete.
I'm not super happy with this behavior change for C++ users,
however as the model is usually used via QML currently, it's
pragmatic to optimize performance for the common case, and it
doesn't technically break QAbstractItemModel semantics, as model
population isn't required to be sync.
There's a decent change this fixes a recently-reported crash as a
by-product:
CCBUG:386630
Reviewers: #plasma, davidedmundson, mart
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D8723
This way when a third party like pinning or dragging from Kickoff sends an absolute desktop file
path we would still only store the application id if possible.
CCBUG: 385594
Differential Revision: https://phabricator.kde.org/D8260
begin() and end() operate on the hash values.
This avoids creating a temporary list just for this.
Differential Revision: https://phabricator.kde.org/D7917
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:
TaskGroupingProxyModel uses a simple QVector<QVector<int>> populated
with source model row indices to represent the task group tree. To
implement QAbstractItemModel::parent(), its implementation of index()
encodes row indices of the top-level vector into the internal ids of
child item model indices. This allows parent() to produce the parent
model index by simply decoding the parent row from the passed-in child
index and call index() with that row.
Top-level row indices shift up and down as the list of top-level items
changes, invalidating those internal ids. QModelIndex is not meant to
be stored, and the proxy model does take care of updating any persis-
tent model indexes with new ids, so this should be fine.
However, where it falls apart is that as internal ids are invalidated,
a QSortFilterProxyModel on top of this proxy (i.e. TasksModel) may end
up with multiple indexes with identical internal ids in its mappings,
causing it to mess up its mappings as it uses them (e.g. taking things
from them). This causes the often-reported crash/assert there.
The fix is to refactor index()/parent() not to rely on row indices as
internal ids, but instead use pointers to internal data structures
instead.
This patch achieves this by changing the map to QVector<QVector<int> *>.
This screams fugly, but the alternative would basically just be to
create some wrapper struct to hide the fugly appeareance a little,
which I don't think is worth it.
On the flip side, it saves a QVector::replace() call as a multable
vector iterator can work directly on a vector without making a copy,
and it's now no longer necessary to manually update the persistent
model indices beyond what endRemoveRows() does implicitly.
BUG:381006
Reviewers: #plasma, davidedmundson
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D7139
Summary:
TaskGroupingProxyModel uses a simple QVector<QVector<int>> populated
with source model row indices to represent the task group tree. To
implement QAbstractItemModel::parent(), its implementation of index()
encodes row indices of the top-level vector into the internal ids of
child item model indices. This allows parent() to produce the parent
model index by simply decoding the parent row from the passed-in child
index and call index() with that row.
Top-level row indices shift up and down as the list of top-level items
changes, invalidating those internal ids. QModelIndex is not meant to
be stored, and the proxy model does take care of updating any persis-
tent model indexes with new ids, so this should be fine.
However, where it falls apart is that as internal ids are invalidated,
a QSortFilterProxyModel on top of this proxy (i.e. TasksModel) may end
up with multiple indexes with identical internal ids in its mappings,
causing it to mess up its mappings as it uses them (e.g. taking things
from them). This causes the often-reported crash/assert there.
The fix is to refactor index()/parent() not to rely on row indices as
internal ids, but instead use pointers to internal data structures
instead.
This patch achieves this by changing the map to QVector<QVector<int> *>.
This screams fugly, but the alternative would basically just be to
create some wrapper struct to hide the fugly appeareance a little,
which I don't think is worth it.
On the flip side, it saves a QVector::replace() call as a multable
vector iterator can work directly on a vector without making a copy,
and it's now no longer necessary to manually update the persistent
model indices beyond what endRemoveRows() does implicitly.
BUG:381006
Reviewers: #plasma, davidedmundson
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D7139
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
This is done in XWindowTasksModel and WaylandTasksModel but was forgotten in LauncherTasksModel.
Differential Revision: https://phabricator.kde.org/D6869
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:
Otherwise we:
* ... don't get startup notifications.
BUG:381500
* ... don't contribute data to recent/most used apps.
This is a surprisingly large oversight.
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D6354
Eike Hein
Yuri Chornoivan
Christoph Feck
Maximiliano Curia
David Edmundson
Friedrich W. H. Kossebau
Kai Uwe Broulik
Laurent Montel
Aleix Pol