Summary:
It's exported and we're including the include path in our cmake so we
had two paths to the same thing included.
Test Plan: Compiled
Reviewers: #plasma, markg
Reviewed By: markg
Subscribers: markg, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D4030
Summary:
this replaces the approach with the expose event in
20b439a4f4 by directly monitoring the xcb screen change
notify native event
Test Plan:
attaching and detaching the external screen on a laptop
configured to deactivate the internal screen upon connection
same behavior as D3777
Reviewers: sebas, davidedmundson, #plasma
Reviewed By: davidedmundson, #plasma
Subscribers: pmuralidharan, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D3822
Summary:
this replaces the approach with the expose event in
20b439a4f4 by directly monitoring the xcb screen change
notify native event
Test Plan:
attaching and detaching the external screen on a laptop
configured to deactivate the internal screen upon connection
same behavior as D3777
Reviewers: sebas, davidedmundson, #plasma
Reviewed By: davidedmundson, #plasma
Subscribers: pmuralidharan, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D3822
Summary:
in a corner case that is used a lot, the internal laptop screen
gets automatically disabled when an external screen is connected.
the only QScreen* available from the QGuiApp gets recycled for the
new screen and there is no signal this switch occurred.
To work around this, as all the view get an expose event when this happen,
monitor the rename of the desktopview's qscreen and manage this separatedly
in the shell.
BUG:373880
Test Plan:
connection and disconnecting an external screen to the laptop
both in the case of internal screen enabled or disabled
Reviewers: davidedmundson, #plasma
Reviewed By: davidedmundson, #plasma
Subscribers: davidedmundson, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D3777
Summary:
in a corner case that is used a lot, the internal laptop screen
gets automatically disabled when an external screen is connected.
the only QScreen* available from the QGuiApp gets recycled for the
new screen and there is no signal this switch occurred.
To work around this, as all the view get an expose event when this happen,
monitor the rename of the desktopview's qscreen and manage this separatedly
in the shell.
BUG:373880
Test Plan:
connection and disconnecting an external screen to the laptop
both in the case of internal screen enabled or disabled
Reviewers: davidedmundson, #plasma
Reviewed By: davidedmundson, #plasma
Subscribers: davidedmundson, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D3777
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
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
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.
this makes the desktops and panels more deterministically
follow the primary screen
* adaptToScreen is useless per se in moveEvent, but what's worse will cause a recursion loop
* disconnect the geometry sync from the old screen
CCBUG:335710
Set all the winId dependent stuff whenever it changes, windows are recreated
upon screen change and we need to make sure the set properties are
honored after changing screens.