index desktop views by qscreen instead of id, making ScreenPool
the single source of truth for the mapping between screen names
and ids. This is less error prone and easier to consistency check
(if view->screenToFollow() is ever different to its has key it will
assert)
The whole logic of screen management is moved to ScreenPool.
ShellCorona will have to never call QGuiApp->screens, but only trust what ScreenPool it's telling it
Also adds an autotests on screenpool which makes a fake wayland server which sends screen added/removed/changed events
There is also the possibility that the screen mapping by screenpool gets
lost or partially lost ( like removal of plasmashellrc but not
appletsrc)
In this case if it was a multimonitor setup there will be containments
assigned to a screen number which doesn't have a known connector.
List them as well, marked as "Unknown 1" "Unknown 2" etc.
This is an edge case of the edge case but it well possible it happens so
it should be managed as well
Allow the Panel to get active keyboard focus via a kwyboard shortcut which will cycle between all panels.
When a panel has focus, the active focus can be navigated around either with tab/backtab or arrow keys.
Simple popup applets which only display an icon will work automatically,
Complex applets like the System tray or the taskbar will have focus that can navigate on all their sub-elements, to activate a particular systray applet or activate a particular window
Co-authored with Benjamin Port<benjamin.port@enioka.com>
CCBUG: 352476
An UI to manage Screen assignment of Containments, the main use case is to recover lost or inactive panels from a display that you can no longer access.
qml part: https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/618
related to https://phabricator.kde.org/T14346
CCBUG: 447044
Access the dialog from Toolbar in Edit Mode (Manage containments)
To show the dialog, simply enter in `edit mode`, then you can :
* See known displays and their panels and desktops, the dialog automatically update when adding/moving/removing a panel.
* Delete a panel or a desktop
* Recover a panel by moving it to an active display (click on move icon, then select the proper action in drop menu)
* Recover a desktop by moving it to an active display, in fact, this will swap it with th targeted desktop
* Modifications are automatically applied
What I've tested:
* Adding a panel, adding some applet on it. Then disabling its display, open the dialog and move it to an active display, restarting session, the panel is here with its applet.
* On another display, add applets (sticky note) on the desktop. Disable this display, open the dialog and move it to an active display, restart session, both desktop were swapped and you see the background (if different) and sticky note available.
when we disconnect all real outputs, we only have a single fake QScreen in this case consider corona to not have screens and remove all desktops and panels. makes easier for a coherent reconstruction when real screens get back and won't save in screen mapping the :0.0 connector name
Refactors XRandr support together with the new Wayland code into a
PrimaryOutputWatcher class.
For X11 it listens to xcb events.
For Wayland it uses the kde_output_management_v2 protocols.
This timer is used to delay the shell state being refreshed and when a new screen is available.
It seems unnecessary to have such a long delay, once screen geometry are stable to work with.
A placeholder screen is created by Qt when no real screens exist. We
don't want to create panels and containments for those, it is a whole
world of pain.
Plasma has a hook to ignore some screens which is extended with this
check.
CCBUG: 419492
Using screenAt(cursor) is a bad idea in general. It doesn't work
properly on Wayland. We can't really tell where our cursor is, so it
always will fall about wherever our top-leftmost screen is.
Instead, just create them wherever we gave focus last.
There is no primary on Wayland, we were trying to make one up and making
everything worse in turn.
Instead, have the screen to connector mapping be stable across
executions. Each screen will look as configured, which makes it all more
predictable and we do not run into cases where we swap displays
configurations because the other one happened to be the primary this
time around.
Plasma had an entire text editor for the script engine in process.
The method for loading this was very convoluted, it loaded a QML file
(in plasma-desktop!) which contained an Item(!) which then loaded a QML
component that showed a widget dialog.
It also means loading a very heavy lib KTextEditor in ShellComponents
which is very heavy. This will get loaded in things like the logout
greeter, which is super slow on the pinephone.
We already had the concept of evalating a script remotely, we can just
hook up the print statement and move the whole executable out.
Technically this is an API break on the plasmashell DBus API, but
pragmatically going from void -> something on the return type isn't
going to break anything.
ShellCorona is created before KDBusService which registers the name.
This causes a problem as we register global shortcuts before plasmashell
--replace has kiled the old application, which in turn deregisters
everything.
We want everything before KDBusService to be as light as possible.
Moving ShellCorona construction is not trivial as some argument parsing
uses that.
BUG: 408310
createWaitingPanels is not guaranteed to create all of them.
Those which have a desktop not ready yet will go back to waitingpanels until new turn.
This scenario sometimes happens during first run scripts or update ones, causing a crash in those cases
The current code is broken as the course of events is:
- we delete the containment
- an existing connect to containment deleted goes to
panelContainmentDestroyed
- this updates m_panelViews and calls deleteLater
- this deleteLater isn't run before other exit handlers
A popup needs to grab the keyboard and the pointer in order to dismiss
itself when another window is clicked. It works perfectly on X11.
On Wayland though, the compositor is responsible for dismissing popups
if some surface of another application has been clicked. Note that I
said "of another application." If user clicks some surface of the same
application, the compositor won't dismiss the popup.
If the application uses only QtWidgets, then the popup will be closed
as expected in both cases. But if the application uses both Qt Quick and
Qt Widgets, e.g. plasmashell, then the popup won't be dismissed if a
QQuickItem has been clicked.
It is a Qt bug, but for the time being, this change introduces an event
filter that monitors Qt::MouseButtonPress events and when needed closes
the active popup widget. This is a workaround.
CCBUG: 379635
ShellCorona is a messy class doing mulitple functions.
This patch splits out all telemetry code into a new class, meaning it's
easier to extend. Code remains the same.
The HIG specifies that actions and menu items should start with action
verbs, and that ellipses should only be used for actions that open a
separate window to complete the action. This commit applies that to the
"Activities..." menu item.
Laurent Montel
Volker Krause
Aleix Pol
Marco Martin
Fushan Wen
Ahmad Samir
Benjamin Port
Cyril Rossi
David Redondo
Alexander Lohnau
Oxalica F
Méven Car
David Edmundson
Nicolas Fella
Xaver Hugl
Vlad Zahorodnii
Nate Graham