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
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
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
This is done in XWindowTasksModel and WaylandTasksModel but was forgotten in LauncherTasksModel.
Differential Revision: https://phabricator.kde.org/D6869
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
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:
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
- 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
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:
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:
When grouping inline, the group subtrees are flattened out into
the top-level list, parents removed, and move() treats groups as
singular entities.
This functionality was previously found in Netrunner's Expanding
Icons Task Manager fork.
This is the first half of the EITM functionality merge.
Reviewers: davidedmundson
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1881
Christoph Feck
Friedrich W. H. Kossebau
Eike Hein
Kai Uwe Broulik
Ivan Čukić
David Edmundson
Martin Gräßlin