On multiscreen (seems to happen only on X11 so far) when screen are
added and moved, sometimes the panel gets moved by the window manager
ending up out of screen boundaries, leaving a screen without panel
a common scenario is:
laptop with external screen connected, panel on internal screen,
close the lid, everything gets moved to the external screen,
the panel will stay out of screen boundaries, but the panel struts are correct
CCBUG:438114
when we disconnect all real outputs, we only have a single fake QScreen in this case consider corona to not have screens and remove all desktops and panels. makes easier for a coherent reconstruction when real screens get back and won't save in screen mapping the :0.0 connector name
The fake drag-and-drop events caused by the panel reuse the real event's
mimeData, and were handled asynchronously. By the time the fake event
has been dispatched from the event loop, the mimeData may already have
been freed. Send the fake events synchronously again.
A guard is added to avoid the original potential bug of infinite recursion.
BUG: 398440
Panel struts may need to be updated when screen configuration changes,
even when the panel isn't resized or moved. Example: screen below the
panel is removed.
Currently the struts are only sometimes updated, that is when
ShellCorona::reconsiderOutputs is called. This is timing dependant since
ShellCorona::addOutput connects QScreen::geometryChange to it, and
geometryChagned signal can arrive before addOutput is called, in which
case the struts aren't updated.
I am not sure if this behaviour is intended, but it's best to not rely
on it. Instead lets just update the struts when screen size changes like
we used to.
There was a previous commit d66d6d57 that is similar, however it got
lost when the dependency on KScreen was removed.
Since now we rely on QScreen, we need to connect the QScreen signal
every time it changes, hence the change being in setScreenToFollow.
There is an error handling path when we fetch the relevant config()
```
KConfigGroup PanelView::panelConfig(...
{
if (!containment || !screen) {
return KConfigGroup();
}
```
which we indiscrimiately call parent() on.
This patch guards that case, which is presumably screen being
temporarily null.
This code is also Plasma 5.8 compatibility fallback, so arguably we
could get rid of it.
BUG: 425711
Summary:
--when the containment background hints are updated then the
panel shadows should be also. In case the background hints
point to NoBackground the panel shadows should be removed
and in case they point to DefaultBackground they should be
drawn again
--PanelShadows::removeWindow has no place in updateEnabledBorders
because the window still lives. When removeWindow was executed
before it was faulty unregistered from PanelShadows and in order for
setEnabledBorders to work again we should need
to execute from start the PanelShadows::addWindow function
FIXED-IN:5.17.3
Test Plan:
--I have created an applet which a PlasmaComponents.Switch button
and toggles panel transparency on user demand easily
Reviewers: #plasma, davidedmundson, mart
Reviewed By: #plasma, davidedmundson
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D25121
Summary:
--when the containment background hints are updated then the
panel shadows should be also. In case the background hints
point to NoBackground the panel shadows should be removed
and in case they point to DefaultBackground they should be
drawn again
--PanelShadows::removeWindow has no place in updateEnabledBorders
because the window still lives. When removeWindow was executed
before it was faulty unregistered from PanelShadows and in order for
setEnabledBorders to work again we should need
to execute from start the PanelShadows::addWindow function
Test Plan:
--I have created an applet which a PlasmaComponents.Switch button
and toggles panel transparency on user demand easily
Reviewers: #plasma, davidedmundson, mart
Reviewed By: #plasma, davidedmundson
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D25121
Summary:
when plasma is starting up, there are no panel views yet
this means that if a thickness (or other values)
are written to the config file and then the resolution changes before
the panel view gets created, we'll have a view that will default
to 30 pixels regardless what the layout js file specified.
This makes the scripting only write to a [Default] group for resolution
dependent properties when panels are not actually present
when they are already there, interact directly with the view which is
the safest option.
the view will use whatever is in the defaults group as default if the
resolution dependent is there, and when a new value is set for a
resolution dependent one, also update the default, which will
be used when screen resolution changes, as new default value
Test Plan:
* With virtualbox, change resolution continuously when plasma is starting up
with an empty setup, panel is the expected size now, as opposed to 30
* Stop Plasma. Change Screen resoluton with plasma *not* running, to a resoluton
still "unknown" to plasmashellrc, then start plasma again. Now the thickness saved
in [Default] is picked, instead of the arbitrary 30
Reviewers: #plasma, broulik
Reviewed By: #plasma, broulik
Subscribers: apol, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D22893
Summary:
With Plasma dialogs & tooltips the mask is only set on the widget itself
if compositing is off. Instead is the mask explicitly passed for the
KWindowEffects.
The recent changes to fix the blurbehind & contrast mask with panels
instead turned to always set the mask on the widget. For some reason
yet to be understood this can sometimes result in an offset by a pixel
between the mask used for painting and the mask used for the window effects.
Aligning the mask setting code with the one for dialogs & tooltips makes
the symptom go away for now, and also delivers consistency.
BBUG: 406380
FIXED-IN: 5.16.1
Test Plan:
Using different themes, including Adapta & Arc Dark, a gap can no longer
been seen. Only with compositing turned off, which is old behaviour due to
the real bug yet to understand completly.
Resizing panels or changing screen resolution also works without breaking
rendering or panel contents interaction.
Reviewers: #plasma, hein
Reviewed By: #plasma, hein
Subscribers: hein, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D21803
Summary:
The macro is on its way to getting deprecated, so we better start
adopting the suggested alternative just as well.
Test Plan: plasmashell runs fine
Reviewers: #plasma, ngraham
Reviewed By: ngraham
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D21493
Summary:
the culript seems the Qt::WindowDoesNotAcceptFocus flag,
removing it makes it possible to have back working text fields in the
panel
Test Plan: works with an ad-hoc applet, notes applet needs fixing
Reviewers: #plasma, #kwin, davidedmundson
Reviewed By: #plasma, #kwin, davidedmundson
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D21319
Summary:
The actual mask is now queried from the panel, there is no more need
for this.
Reviewers: #plasma, mart
Reviewed By: #plasma, mart
Subscribers: davidedmundson, mvourlakos, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D21013
Summary:
The mask of a panel depends on things like borders set or window size,
but nothing else on it. So it should be updated as last in the queue of
things to update.
There might be still state changes not properly propagated, but this is
a move in the more expected direction.
Reviewers: #plasma, broulik
Reviewed By: #plasma, broulik
Subscribers: apol, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D21012
Summary:
Plasma themes might define non-full-rect shapes for panels (e.g. round
borders for panels not filling the whole width/height).
The old code tells the window manager to blur the full rect of a panel
window, resulting in unwanted artifacts around the panel shape for
non-full-rect themed panels.
With the Panel.qml item of the desktop packages exposing some optional
"panelMask" property now, we can query for the shape and only use the
painted area when telling the window manager where to blur behind or
changing the background contrast.
This also follows the logic as already applied for dialogs or other window
elements like tooltips which are rendered using a Plasma theme.
Test Plan:
The Oxygen Plasma theme no longer has blurry corners on panel edges.
Also still works as before when using non-composing window manager.
Reviewers: #plasma, mart
Reviewed By: #plasma, mart
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D20204
Summary: makes sure the flag is set on time
Test Plan: can't get the panelcontroller in the taskbar anymore
Reviewers: #plasma, hein, broulik
Reviewed By: #plasma, hein, broulik
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D18186
Summary:
To test if the panel is under the cursor we used:
if (geometry().contains(QCursor::pos(screenToFollow()))) {
Unsurprisingly in wayland we don't know the cursor position once it's
left our window. Behaviour seems to be undefined.
We were already using enter and leave events to start the autohide
timer, so we may as well rely on that for tracking state too.
BUG: 377838
Test Plan:
Tested mouse in, mouse out
Tested mouse in and waiting and panel stayed open
Tested opening wifi applet and closing it
That will trigger the restoreAutoHide method as an applet status changed
The panel stayed open because the mouse was on it.
Reviewers: #plasma, mart
Reviewed By: #plasma, mart
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D10101
This fixes opening panel controller while an applet config dialog was open.
It would find that we want to show config for a panel but find a config is already open, so it would just close it,
even though it was not the panel controller (which should be toggleable) but another applet config.
While at it restructure if statements a bit.
Differential Revision: https://phabricator.kde.org/D9799
Summary: QUrl::fromLocalFile can't be used when packages are qrc
Test Plan: plasashell loads correctly with packages from qrc
Reviewers: #plasma, davidedmundson
Reviewed By: #plasma, davidedmundson
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D9176
Marco Martin
Aleix Pol
Laurent Montel
Alexander Lohnau
Bharadwaj Raju
Vlad Zahorodnii
Niccolò Venerandi
Alois Wohlschlager
Andrew Chen
David Edmundson
Xaver Hugl
Ahmad Samir
Yuri Chornoivan
Michail Vourlakos
Friedrich W. H. Kossebau
Kai Uwe Broulik