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:
qml gridview don't have an official way to ensure the
current index is visible when the view is first instantiated,
the only way we have is to do positionViewAtIndex when we know the
proper space has already been allocated (Component.onCompleted
is way too early) we used to do that on onCountChanged, but that
too seems to early sometimes, as the selected wallpaper
is visible only sometimes, attaching it to onContentHeightChanged
seems to be more reliable (for all branches)
Test Plan: proper wallpaper is visible every time the window opens
Reviewers: #plasma, davidedmundson
Reviewed By: #plasma, davidedmundson
Subscribers: hein, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D4648
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:
Commit 72e39f083a broke the kded module. Turns out that the old code
just forced a refresh of the `remote:/` QUrl, so we can just do that
explicitly and remove all the old cruft.
While at it, use a KDirWatcher that just watches the
`.local/share/remote/` folder, instead of checking *every* unrelated
QUrl emitted by KDirNotify.
Test Plan:
Adding/deleting/editing .desktop files in `.local/share/remoteview` now
automatically reloads the `remote:/` url in Dolphin or Folder View.
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D4573
Otherwise the positioner will get completely confused.
When a notification is closed, the popup will already be closed in response to sourceRemoved.
Also, when triggering an action, call closePopup instead of hiding the popup.
(cherry picked from commit b97fdfa293)
Differential Revision: https://phabricator.kde.org/D4632
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: This is needed so Plasma::DataEngine can construct the metadata
Test Plan: Debug. Lots of debug.
Reviewers: #plasma, broulik
Reviewed By: #plasma, broulik
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D4554
requestActivate() doesn't raise the window. The same had been done in PanelView but not
for DesktopView. This way a minimized config dialog (e.g. you want look at the wallpaper
in its full glory) will be raised if you open it again through the applet/desktop context menu.
CHANGELOG: A minimized config dialog on the desktop (e.g. wallpaper settings) will now be un-minimized when trying to open it multiple times
Reviewed-By: David Edmundson
This part reverts commit b9af991403 which
changes plasmoids and SNI items to activate on mouse release instead of
mouse click.
This messes with xembedsniproxy which is relaying the mouse press
signals to the exembed client. Now at the time of relay, if the client
application queries the mouse state itself it's going to be wrong and
that breaks GTK.
BUG: 375930
FIXED-IN: 5.9.2
Reviewed-By: David Edmundson
Summary:
We somehow ended up with two applets named Application Menu; kicker and
the global menu bar. Both having the same name is confusing.
This is a translation break on a stable branch, but it's a bug fix.
CCMAIL:kde-i18n-doc@kde.org
BUG: 375478
Reviewers: #plasma, mart
Reviewed By: mart
Subscribers: mart, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D4454
Summary:
Commit 72e39f083a broke the remote ioslave from Dolphin Details view
mode, because of missing slashes or otherwise broken `QUrl`s.
BUG: 376131
FIXED-IN: 5.9.2
Test Plan: `remote:/` now works again from Dolphin Details view mode.
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D4480
Take into account the label's height for minimum size. When we resize the applet super tiny,
it's likely text wraps onto two lines, so use a two line text as minimum (it already does that for preferredHeight anyway).
Differential Revision: https://phabricator.kde.org/D4477
Summary:
after the recent set of changes to disqualification we ended up with a bit
too lax disqualification. if we saw the exec OR the storageid we'd
hence forth disqualify a service with either of them being equal.
in case of system settings this causes a match problem. systemsettings
has two desktop files one !KDE and one OnlyKDE they are however exactly
the same except for a different name and storageid. as a result if the !KDE
one is encountered first it will be disqualified on account of
noDisplay=true and marked as seen. when the OnlyKDE systemsettings is then
iterated it will already have the Exec entry in the seen list and be
disqualified on account of that.
to prevent this type of confusion make it a requirement to match both
storageid AND exec before disqualifying.
it may actually be suitable to drop the exec altogether. say I copy firefox
into the user local applications dir and set it NoDisplay=true but change
the exec. this would still lead to the system-wide firefox being found as
it is not getting disqualified. long story short: maybe we should
disqualify services solely on the storageid?
Test Plan:
- new autotest case
- fails without changes
- passes with changes
Reviewers: broulik
Reviewed By: broulik
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D4415
Otherwise it fails to lock the screen and since it waits for the lock screen to show up before switching, it never does it.
BUG: 375941
FIXED-IN: 5.9.1
Differential Revision: https://phabricator.kde.org/D4470
Eike Hein
Kai Uwe Broulik
Marco Martin
l10n daemon script
Jonathan Riddell
Elvis Angelaccio
David Faure
David Edmundson
Harald Sitter