Summary:
It makes no sense to modify the focus of containment within it's
FocusScope, and activeFocus will be set correctly by code in
QQuickWindow. Especially as it doesn't set it back.
The only way this would make any sense is if someone in Desktop is
incorrectly using "focus" when they mean to use "activeFocus". This code
was introduced to fix a bug in the toolbox (331971) where someone was
making the mistake above.
That toolbox code has been subsequently fixed properly, leaving this as
dead code.
Test Plan:
Toolbox still closes appropriately.
Everything else still seems the same
Reviewers: #plasma, broulik
Reviewed By: #plasma, broulik
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D2446
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
Summary:
On Wayland we need special glue code to make KWin aware of the position
the DesktopView wants to be. This change ensures that DesktopView calls
setPosition on the PlasmaShellSurface on creation and whenever the screen
geometry changes.
With this change DesktopViews are properly positioned in a multi-screen
setup on Wayland.
Reviewers: #plasma_on_wayland
Subscribers: plasma-devel
Tags: #plasma_on_wayland
Differential Revision: https://phabricator.kde.org/D1889
Summary:
The default window type is desktop, so we should also tell Qt that it's
a frameless window. Not doing so means that on construction of the
platform surface our plasma-integration plugin will request a server
side decoration for the window. Which means KWin creates a deco and
destroys it again once the flag propagated. But it also means that the
window gets misplaced due to the temporarily added deco.
By setting the flag the plasma-integration never asks for the deco to
be created in the first place and in all my tests so far the window was
positioned correctly.
Reviewers: #plasma, sebas, mart
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1156
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
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
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
Otherwise it enters an infinite loop where the DesktopView starts to be
moved from a screen to another. That happens on XCB (only platform I've
tested) because setScreen and setGeometry will send an XCB event that is
later processed by the application again.
This should probably backported to Plasma/5.4, but considering I'm running
Qt 5.6 I would really appreciate it if someone can check if it works for
him and cherry-pick it there. An easy way to test is to change the primary
screen (in a 2-screen set up) using the kcm or xrandr.
CCMAIL: plasma-devel@kde.org
This is fallout from the shared engine changes.
With the shared view, engine()->rootContext() is not the same as
rootContext(). One being global, the other being per window.
This resulted us in us overwriting the same "desktop" context property,
and so Desktop.qml always had the property desktop pointing to the last
created desktop view.
The most obvious symptom is that the add widgets dialog appeared on the
wrong screen.
BUG: 351292
REVIEW: 124792
Set Qt::FramelessWindowHint to prevent QtWayland to create it's window
decoration.
This change was developed, compiled and tested in a kwin_wayland session
with each application running in the QT_QPA_PLATFORM=wayland.
REVIEW: 124210
This fixes ksmserver not being able to logout or shutdown correctly as
it was unable to kill Plasma.
Tests showed that pressing alt+f4 no longer kills the window anyway
(possibly a change in kwin?)
BUG: 338360
REVIEW: 121004
The hack we used to have is not working anymore because they changed how
Qt works (And it was a hack after all).
On the other hand, on Qt 5.4 we can use the API I added for this purpose,
so listen to screen removed before the window is shuffled somewhere else
so we can cleanly remove the view.
Reviewed by DJ Edmundson
Only set the screen right before triggering show(), otherwise it can mess
up for reasons I don't know.
Also I prefer not to pass the screen in the constructor, given that we
move the DesktopView instances across screens and it gives the wrong
impression that the view is tied to the screen.
Marco Martin
David Edmundson
David Rosca
Martin Gräßlin
Kai Uwe Broulik
Montel Laurent
Aleix Pol
Lukáš Tinkl
Aaron Seigo