Views shouldn't decide to delete themselves.
ShellCorona is responsible for managing them, it should be the one
managing them in all cases.
bring panelContainmentDestroyed and desktopContainmentDestroyed in line
REVIEW: 127225
Summary:
If the window's platform surface was destroyed, there is also
no shadow to be removed.
Both X and Wayland code will try to create the platform surface
again, and it will lead to crash in other code that doesn't expect
platform surface to be created when the containment is being deleted.
This fixes crash in PanelConfigView::event when removing panels.
Reviewers: graesslin, #plasma
Reviewed By: graesslin, #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D951
Summary:
Since Qt 5.5 there is a dedicated event when a PlatformSurface gets
created. This allows us to know when we need to setup the Wayland
integration.
Reviewers: mart
Subscribers: plasma-devel
Differential Revision: https://phabricator.kde.org/D819
We were rejecting all key presses that had modifier in it, this included upper-case letters because of Shift being pressed.
Accept keys where *only* the Shift modifier is pressed, too.
BUG: 353959
FIXED-IN: 5.6.0
Differential Revision: https://phabricator.kde.org/D902
We were mixing KScreen and QScreen API.
Corona.cpp checks we are requesting a containment for a valid screen
if (screen >= 0 && screen < numScreens()) {
This fails as numScreens() is Qt API based, whereas the signal we're
adding the output for is ShellCorona::addOutput
BUG: 351777
REVIEW: 126961
Prevents them from being hidden by show desktop.
They are for configuring things on the desktop, so this makes sense. Also allows to configure
an applet when it has been dropped from Widget Explorer which enters show desktop mode.
REVIEW: 126947
this manages the new systray: if a config for a containment is asked,
treat it like an applet if it's not the actual panel containment
behavior is not changed for anything else
Emitting objects in another object is weird.
ShellCorona::availableScreenRect knows what properties of panelview we
use, so tracking of property changes should be in ShellCorona.
Also simplify ShellCoronaCode, if the rect changes the region has also
implicitly changed. We can handle that in one connect.
REVIEW: 126576
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
engine()->rootContext() will give a different result to
rootContext() when using a shared engine.
One being in the right context, the other being the context of the
shared engine. Using the latter means two panels end up sharing the same
object which leads to some interesting results and QML crashes in
QV4::QObjectWrapper::wrap when one gets deleted.
I've tested against 356545, but I think it's the cause of a lot of the
mystery QML bugs we couldn't figure out.
BUG: 356545
BUG: 355885
BUG: 356916
REVIEW: 126491
Last patch has a reggression due to QtQuick issue (only on Xcb):
QEvent::Leave is triggered after QEvent::MouseButtonPress Qt::LeftButton
BUG: 354651
REVIEW: 126331
Turns out that this method is sometimes called at the time where the
virtualGeometry() is invalid -- which sounds pretty much like a Qt bug,
but it isn't exactly the first bug in screen handling in Qt5. Rather
than producing values which are surely invalid, try to cover up the
mess.
REVIEW: 126216
Plasmashell was incorrectly listing update scripts from
XDG_DATA_DIRS/plasma/shells/<package>/updates when it should have been
listing from XDG_DATA_DIRS/plasma/shells/<package>/contents/updates.
This needed to be corrected because Plasma 5.5 is now bundling a
migration script for Kickoff favorites and installs it into the
correct location.
Distros may have to adjust the install location for their custom
update scripts for their Plasma 5.5 packages, if they haveany. Fedora
is known to be affected.
CCMAIL:rdieter@math.unl.edu
CCMAIL:kde-packager@kde.org
Otherwise ensureWindowType calls winId, triggering a window creation and
since the geometry is rect(0,0,0,0), the view is moved to the screen that
contains 0,0.
BUG: 353975
Currently we're hitting a bug where the panel won't be displayed in the
correct position because of how the screen it's in is computed. See:
https://codereview.qt-project.org/#/c/139533/
This patch makes sure there's no off-by-1 issues by placing the screen
initially at the center.
To move the panels of screen [i] to the next screen, we should query for
the panels of DesktopView [i], not of DesktopView [i + 1]. Otherwise the
panels aren't shifted to the new screen. Thus QT shifted the
panels itself, but hid them afterwards. Besides the panels were not
visible, it raised an assert in screenInvariants().
REVIEW: 125694
When a new primary output gets connected, it's possible that
primaryOutputChanged() is called before addOutput(). When addOutput()
was called afterwards, this led to two DesktopViews on the same
screen. This raised an assert in screenInvariants().
Solve this by not doing anything in primaryOutputChanged() when the new
primary output is not used for a DesktopView yet.
REVIEW: 125693
We have a
connect(KWindowSystem::self(), &KWindowSystem::showingDesktopChanged,
[dashboardAction](bool showing) {
dashboardAction->setText(showing ? i18n("Hide Dashboard") :
i18n("Show Dashboard"));
in the class constructor. Changing it here too is pointless.
REVIEW: 125669