Summary:
The visibility mode needs to be passed to KWayland by mapping to the
PanelBehavior. This is required to pass the correct hint to KWin to
adjust the layering, etc.
BUG: 368499
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D2789
Summary:
KWin starting with 5.7 supports struts on panels between screen edges.
Thus we can start setting struts on such panels, it won't exclude a
complete screen. But we don't know how other window managers handle it
and it's in general a rather "dangerous" change.
Thus to not affect other window managers, we check whether KWin is
running and only allow struts on thus panels if KWin is running.
Unfortunately we need to test this every time we go into the code path
as the WM might have changed.
In case the user replaces the window manager at runtime this still can
result in a bad situation.
BUG: 94470
FIXED-IN: 5.8.0
Test Plan:
Tested whether it works in general in X11. Further testing
needed by X11, multi-screen users.
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D2164
Summary:
We used to append them, but that didn't work well and was crashing plasmashell
on fresh start.
A default desktop would be created alongside with the one provided by the
layout instead of replacing it.
If a layout wants to provide an additional screen for a desktop in the secondary
screen, it should specify the screen.
Test Plan:
Now the plasmashell tests pass. In fact I noticed it was broken due to an e-mail
Jonathan sent me that the test on neon was timing out. The test in neon will
freeze when the test crashes. Probably something to look into.
It can be reproduced by running:
```
xvfb-run -a --server-args="-screen 0 1024x768x24" dbus-launch --exit-with-session <exec>
```
Where `exec` is the process we need to run.
Now the test passes.
It's a crash that I had reproduced locally in the past. I can't now.
Reviewers: #plasma, mart
Reviewed By: mart
Subscribers: sitter, jriddell, plasma-devel, #neon
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D2117
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