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)
Appearantly right() / bottomRight() / topRight() returns values with 1
pixel x off for historical reasons and hence 1px gap. This causes the
autohide panel not hiding automatically.
BUG: 339323
BUG: 340549
FIXED-IN: 5.3
REVIEW: 123136
Notifications dataengine checks the applicationDisplayName() against the
event title and if it same it allows to 'spam' aka it will not merge
similar notifications. But when we started to use KAboutData this broke
functionality. KAboutData will set only properties available in
QCoreApplication and hence applicationDisplayName will be different.
This fixes it by setting applicationDisplayName.
BUG: 345149
FIXED-IN: 5.2.2
This reverts commit aba0ad1268.
The reason for revertion is that it leaks pixmaps.
QX11Info::display should not return a nullptr if there is no QScreen.
This needs fixing in Qt, not workarounds in our software. None of our
X11 specific code in plasma-workspace or frameworks can handle the case
that the Display* or xcb_connection_t* becomes null suddenly. Neither
can Qt internally. If it would happen Qt would abort.
The only application in our workspace which would be "somewhat" safe
is KWin because it caches the returned Display after first invokation
to QX11Info::display.
This is to keep up with the Qt 5.5 changes with null QScreen. BT:
#0 XInternAtom (dpy=0x0, name=0x7f1195725664 "_KDE_NET_WM_SHADOW", onlyIfExists=0)
at /var/tmp/portage/x11-libs/libX11-1.6.2/work/libX11-1.6.2/src/IntAtom.c:174
#1 0x00007f11956e438c in PanelShadows::Private::clearShadow (this=<optimized out>, window=0x7f119958ff90)
at /var/tmp/portage/kde-plasma/plasma-workspace-5.2.1/work/plasma-workspace-5.2.1/shell/panelshadows.cpp:494
#2 0x00007f11956e7139 in PanelShadows::removeWindow (this=0x7f119593b060 <(anonymous namespace)::Q_QGS_privateDialogShadowsSelf::innerFunction()::holder>, window=window@entry=0x7f119958ff90)
at /var/tmp/portage/kde-plasma/plasma-workspace-5.2.1/work/plasma-workspace-5.2.1/shell/panelshadows.cpp:142
#3 0x00007f11956dd8f5 in PanelView::~PanelView (this=0x7f119958ff90, __in_chrg=<optimized out>)
at /var/tmp/portage/kde-plasma/plasma-workspace-5.2.1/work/plasma-workspace-5.2.1/shell/panelview.cpp:124
#4 0x00007f11956dd9af in PanelView::~PanelView (this=0x7f119958ff90, __in_chrg=<optimized out>)
at /var/tmp/portage/kde-plasma/plasma-workspace-5.2.1/work/plasma-workspace-5.2.1/shell/panelview.cpp:125
#5 0x00007f11956effa8 in ShellCorona::removeView (this=0x7f1196c19b40, idx=0) at /var/tmp/portage/kde-plasma/plasma-workspace-5.2.1/work/plasma-workspace-5.2.1/shell/shellcorona.cpp:710
#6 0x00007f11956f0038 in ShellCorona::remove (this=this@entry=0x7f1196c19b40, desktopView=<optimized out>)
at /var/tmp/portage/kde-plasma/plasma-workspace-5.2.1/work/plasma-workspace-5.2.1/shell/shellcorona.cpp:662
#7 0x00007f11956f009f in ShellCorona::screenRemoved (this=0x7f1196c19b40, screen=<optimized out>)
at /var/tmp/portage/kde-plasma/plasma-workspace-5.2.1/work/plasma-workspace-5.2.1/shell/shellcorona.cpp:743
Signed-off-by: Lukáš Tinkl <lukas@kde.org>
REVIEW: 122909
This allows shells to know the current xsession by evaluating
DESKTOP_SESSION variable
Useful for plasma-mediacenter shell session file, that way pmc shell
will know when to load
Reviewed-By: Marco Martin <mart@kde.org>
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
Emitting dbus signals allows interested parties to be notified about
OSD changes. E.g. the lock screen might want to show the OSD values,
but blocks the actual OSD, so it needs to be informed about changes
to react on them.