When separateLaunchers is false and there are two opened pinned tasks
and one launcher icon, dragging the launcher icon to a position between
the two pinned tasks always fails for the first time.
The general idea of this fix is to make sure after every move operation,
pinned launhcer item and the corresponding opened window still stay
together.
BUG: 448912
FIXED-IN: 5.26
Otherwise the launcher items can't be dragged until the manual sort map
is reset after porting to QConcatenateTablesProxyModel, becuase in
TasksModel there is no slot for modelReset, and in KConcatenateRowsProxyModel,
after receiving a modelReset, there will be a rowsAboutToBeInserted signal,
but not in QConcatenateTablesProxyModel.
The LauncherTasksModel tried to avoid a model reset by making certain
assumptions to save a few cycles. Ultimately this was misguided, in-
correctly not evicting the internal app data cache as well as causing
a lot more work in the view trying to compute layout deltas and some-
times causing a few frames of ugly animations.
There likely _is_ some optimization potential here, but it needs to
be done smarter later on.
While at it, also remove some unused related includes that are likely remnant from before
this was all done centrally in TaskTools
Differential Revision: https://phabricator.kde.org/D28906
Summary:
launchersOrder and the actual url data can be different:
in case of preferred:/ urls launcherorder will have that for
(for serialization) and the actual appdata url will be decoded as for
instance Applications:firefox.desktop.
this url is the one that needs to be compared to know the actual
launcher order
BUG:418483
Test Plan: firefox stays in first position when pinned as preferred://browser
Reviewers: #plasma, ngraham
Reviewed By: ngraham
Subscribers: ngraham, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D28632
Summary:
launchersOrder and the actual url data can be different:
in case of preferred:/ urls launcherorder will have that for
(for serialization) and the actual appdata url will be decoded as for
instance Applications:firefox.desktop.
this url is the one that needs to be compared to know the actual
launcher order
BUG:418483
Test Plan: firefox stays in first position when pinned as preferred://browser
Reviewers: #plasma, ngraham
Reviewed By: ngraham
Subscribers: ngraham, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D28632
The code tried hard to ignore garbage URLs, as Qt is quite lenient, e.g. QUrl("Garbage Url") is still valid.
There is no way to change the strictness of a QUrl after creation,
so the code would enforce it by doing QUrl strictUrl(inputUrl.toString(), QUrl::StrictMode).
However, toString() defaults to PrettyDecoded which avoids percent-encoding and keeps spaces
in tact which is not a valid thing to have in a strict URL.
Effectively, we want to ensure a URL is either a valid path to a local file,
or one of the special applications (for menu ids), or preferred for preferred applications, like web browser,
BUG: 385727
FIXED-IN: 5.18.0
Differential Revision: https://phabricator.kde.org/D26941
Summary:
Includes, among other things:
* A refactoring towards supporting more than one desktop per window,
for an eventual virtual desktops / activities merge
* A scheme for process-internal window ids on Wayland as DND payload
so DND in and to the Pager works in the shell
* Implemented various previously missing behavior in WaylandTasksModel
such as implicit moves of windows to the current desktop on various
actions
* Expanded VirtualDesktopInfo API so the Pager can better abstract
over windowing systems
* Implicit internal sharing of VirtualDesktopInfo since there are many
more instances now
* Various cleanups
Still missing:
* Fixing the VirtualDesktops data role in the grouping proxy
* The protocol doesn't have desktop creation/destruction yet, so some
of the related logic is still missing
* Some FIXME TODOs in the code when I was unhappy with the current
KWayland API
This code is largely untested and subject to change.
Depends on D12820 and relates to T4457.
Reviewers: mart, mvourlakos, davidedmundson
Reviewed By: davidedmundson
Subscribers: alexde, anthonyfieroni, zzag, ngraham, abetts, plasma-devel
Tags: #plasma
Maniphest Tasks: T4457
Differential Revision: https://phabricator.kde.org/D13745
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
Fushan Wen
Aleix Pol
Laurent Montel
Volker Krause
Nicolas Fella
Alexander Lohnau
Eike Hein
David Redondo
Kai Uwe Broulik
Marco Martin
Christoph Feck
Friedrich W. H. Kossebau
Ivan Čukić
David Edmundson