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
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
execute a script from the look and feel package when
an applet is added, adding to the script environment
"applet" that wraps the currently added applet and
"containment" that wraps its containment.
from there the javascript part can do anything it can do
in the startup script as well.
In case of containments, "applet" and "containment" will
be the same thing
REVIEW:125562
since we can't subclass Dialog (created from QML) inject a class
that will control it with event filters from the shell
(in an eventfilter as well installed on the qapp)
REVIEW:124555
This fixes a crash on shutdown when it has already deleted its
views but someone calls into availableScreenRect
BUG: 348511
FIXED-IN: 5.4.0
REVIEW: 124323
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
reconsiderOutputs() may be called before the async config fetching
operation (KScreen::GetConfigOperation) has finished, so the pointer is
still null at that point. This can happen if qApp::screenRemoved fires
before kscreen was able to start the backend loader and pass back a
ConfigPtr.
The bug is rooted by in the dual-use of libkscreen and qApp's QScreen
handling. The timings here produce this race condition. This patch
should be quite safe, though, since it doesn't change the logic, but
rather makes sure this race condition bails out nicely by falling back
to just waiting until a kscreen config has arrived (which will happen
right after).
BUG:346590
REVIEW:123648
FIXED-IN:5.3.1
CHANGELOG:Fix crash on Plasma startup caused by a race condition
all scripts in the folder
$prefix/share/org.kde.plasma.desktop/updates will
be correctly executed now
(other shell packages will have their name instead of
org.kde.plasma.desktop)
Why queued? this is usually triggered after a context menu closes
due to its sync,modal nature it may eat some mouse event from the scene
waiting a bit to create a new window, the dialog seems to reliably
avoid the eating of one click in the panel after the context menu is gone
Why queued? this is usually triggered after a context menu closes
due to its sync,modal nature it may eat some mouse event from the scene
waiting a bit to create a new window, the dialog seems to reliably
avoid the eating of one click in the panel after the context menu is gone
if the containment graphics object still exists for an instant
it can still access things that are not valid anymore while the
corona is being deleted, such as availableScreenRect
BUG:343574
if the containment graphics object still exists for an instant
it can still access things that are not valid anymore while the
corona is being deleted, such as availableScreenRect
BUG:343574
There is an issue where as m_activityConsumer starts the
kactivitymanagerd, as KAMD is starting the serviceStatus will be not
running.
Whilst we are loading the kscreen config, the event loop runs and we
might find KAMD has started.
m_activityConsumer will change from "not running" to unknown, and might
still be unknown when the kscreen fetching is complete.
If that happens we want to continue monitoring for state changes so we
can finally load when it is up
BUG: 342431
Instead of keeping the state, expect the code to follow the order it's
expected from it.
Bumps kf5 requirement to 5.4 (i.e. master as of today).
REVIEW: 121244
Now kscreen initialization is asynchronous, always wait for the screen
initialization to happen. Otherwise we'll end up in different occasions
where the configuration is null.
Furthermore, don't try to start loading the shell until the configuration
has been fetched.
CCMAIL: dvratil@redhat.com
David Edmundson
Marco Martin
Montel Laurent
David Kahles
David Edmundson
Bhushan Shah
Kai Uwe Broulik
Martin Gräßlin
Aleix Pol
Jan Grulich
Sebastian Kügler
Lukáš Tinkl
Ivan Čukić
Dan Vrátil