loadScriptInInteractiveConsole requires user interaction which blocks
some purposes, like setting the desktop background from an app.
This runs a given script directly from a passed string without any
prompts.
CCBUG: 217950
REVIEW: 125648
Makes it possible to test how/if a plasmoid behaves correctly on the most
similar environment possible to what the user would find on a production
system.
* Loads a plasmoid on a panel and the desktop.
* Lets it test his own stuff (loading test/test.qml within the plasma
package)
* Terminates with an error if it wasn't successful
REVIEW: 127346
Remove unused variables
Make sure accessing elements within an assert doesn't change the state of
the class.
Don't keep checking if a variable is not null.
Summary: This way the close-on-focus-lost does not happen
Reviewers: mart, broulik
Reviewed By: broulik
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1093
Make use of Qt5.5 API QQuickWindow::sceneGraphError rather than catching
the errors in a message filter.
I also merged with existing warning where contexts could be created, but
compiling shaders would not work.
BUG: 358869
REVIEW: 127254
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
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
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
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