I noticed that panels had borders on all sides and it turns out PanelShadows was never
actually told which sides should have shadows.
To reduce code duplication I expose the enabled borders as property to the Panel.qml
which itself does the same calculation from QML again and does it many times.
Differential Revision: https://phabricator.kde.org/D1756
Don't save and restore panel length
length gets overriden from the QML side so there is no point loading and
restoring it.
This also simpifies code somewhat removing places where we clearly did
the same bit of code twice.
The basic design of Plasma is that scripts and and the shell (in theory)
manipulate a tree of basic applet geometry and configs.
Plasmashell then reacts to those changes and displays them visually with
a distinct separation between the layout and UI.
Panel's scriptengine seemed to do away with all, and try and manipulate
the graphic object directly..which might not exist and that leads to
complex code.
This changes it to read/write from the same config object as
PanelView will use. More akin to how the script engine for applet and
contiainment works.
If there's a view for this panel, we update immediately, otherwise it'll
just get loaded when it's needed. PanelView::reload() has the error
checking/bounds management so no point duplicating that.
BUG: 355918
REVIEW: 125921
Use KWin to lower/raiser panel in windows can cover mode with edge
activation like autohide does.
This means if you have a maxmised menu you can still open the panel by
moving the mouse to the bottom of the screen
BUG: 343448
This change introduces the first part of Wayland integration. If
running on platform Wayland we try to bind the org_kde_plasma_shell
interface through the help of KWayland client library. If this interface
is available we can use it to create a PlasmaShellSurface for the
PanelView's window and mark that as a panel.
A compositor with support for the org_kde_plasma_shell interface can
use this information to make the window operate as a panel.
REVIEW: 124054
Workaround a lack of API from Qt where it will decide to move the panels
around without us being able to control it.
This patch overrides the QWindow::screenDestroyed slot to be able to decide
where to move the Panel or whether it needs to be removed. This is
considered a workaround and should be removed once the new API is in and
released.
See also: https://codereview.qt-project.org/#/c/88351/
BUG: 335710
This way, we don't need to have everything being repainted when geometries
change while constructing the panel.
Also don't connect to screen changed until everything is initialized and
the panel is displayed.
This broke screenForContainment because the Panel didn't know where it
would be placed when the panel is being set. This shouldn't be the case
anymore.
BUG: 334500
CCBUG: 334502
At the moment the Panel didn't have any code to react status changes from
the containment (and therefore its applets).
This patch aims to add this, only problem being that it doesn't work. The
"unhide requested" and "unhiding" messages are being displayed though.
I've been looking for the code that does the actual display of the
auto-hiding panels and I wasn't able to find it, help is welcome.
REVIEW: 117563
Kai Uwe Broulik
Aleix Pol
David Edmundson
David Edmundson
Martin Gräßlin
Marco Martin
Aaron Seigo