The code is meant to add the entry if it's valid, then watch for
changes. Somehow we end up only monitoring if it was valid initially.
This doesn't make sense.
This means if the menu loads before the backend we don't update
correctly when it does load.
CCBUG: 423526
BUG: 427779
The system actions model recently changed behavior to always present all
possible actions, with `AbstractEntry::isValid` driving the model role
`Kicker::DisabledRole` so that views can e.g. grey out unavailable
actions.
This was perceived as a regression by users who are annoyed at e.g.
`Hibernate` being visible when their system setup precludes it more or
less permanently.
This patch reverts this behavior.
Note that the dynamic approach we had permanently wasn't very great
anyway, as the associated favorites models would remove entries when
they became invalid, and they wouldn't come back automatically when the
entry were to become valid again. In effect that means when you added one
of these actions to e.g. the Kicker sidebar and it became unavailable
it would disappear until re-added anyways.
I can imagine use cases where dynamic behavior would be useful to have -
let's say disabling Shutdown/Reboot while a critical system update is
being performed. But in that case we'd need to fix the favorites
behavior and add some way to inform the user why the action is disabled
for a good user experienced anyhow.
BUG:426645
This patch adds a new enabled role to kicker items instead of creating
and deleting them if they're not available due to configuration.
It ports to the new session code in libkworkspace dropping our need for
KDE4Support.
From: D20237
Forward the action information to the model and pass all information to run.
This way future me will not have to wonder why actions don't work when he touches this area of code again.
Differential Revision: https://phabricator.kde.org/D11927
Summary:
The favourites are based on KAStats (already released version) **and kactivitymanagerd master (to be released with the next Plasma release)**. It allows favourites to be set to all activities, or the user can choose which activities to show a specific favourite application on.
This change covers applications, files and contacts, other favourites are still based on the old model (now named SimpleFavoritesModel).
{F1028047}
Test Plan:
Tested in Kicker, Dashboard and Kickoff the following:
Transitioning mechanism:
- load default favorites for the blank user
- load custom default favorites set in the plasmoidsetupscripts script for Kicker
- transition old results - when transitioning, merge the favourites from all launchers. The ordering for each launcher is kept separate (newly added items due to the merge go to the end)
Favorite manipulation:
- right-click add favorite to all activities
- right-click remove favorite from all activities
- right-click add favorite to specific activity (current)
- right-click remove favorite from specific activity (current)
- right-click add favorite to specific activity (not current)
- right-click remove favorite from specific activity (not current)
- right-click move from all to specific
- right-click move from specific to all
- right-click move from one activity to another
- dnd reorder items in the model (up)
- dnd reorder items in the model (down)
- dnd add to favorites at a specific position
Other:
- launch the application
- ordering persists after restart
- ordering from the previous is kept on the activity that has no ordering
Reviewers: mart, hein
Reviewed By: hein
Subscribers: Zren, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D3805
* Not just apps, also documents and contacts can now be added
to the favorites. All types of content have their full context
menu action list available also in the favorites sidebar.
* Contact favorites use the contact photo as icon, with a circular
alpha mask and the presence status icon as overlay badge.
* Adding/removing favorites from context menus now works every-
where, e.g. also in KRunner-based search results.
* Far fewer actions now cause a full rebuild of the model tree
and instead only delta updates, as a side-effect of adding a
mechanism for this to e.g. handle status changes for contact
items.
* Various bugs around hiding/unhiding apps got fixed.
* Lots of code cleanup + less coupling all around.
This version is a mostly-from-scratch reimplementation of
the Plasma 1 version.
Some minor-in-scope loose ends are left, both external and
internal to the code; check TODO for whether your issue is
already known.
Alexander Lohnau
Michail Vourlakos
Eike Hein
Bhushan Shah
Laurent Montel
Kai Uwe Broulik
Ivan Čukić