https://bugs.kde.org/show_bug.cgi?id=393881
Alexander Kandaurov <aakandau...@yandex.ru> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |aakandau...@yandex.ru
--- Comment #15 from Alexander Kandaurov <aakandau...@yandex.ru> ---
I also experience a similar behavior and did some research on it.
First of all, in my case the bug is triggered when
a) the screen configuration at the login screen is different from what is set
up in KDE settings, and
b) the screen configuration change happens after plasmashell has already
started and loaded some widgets.
So, a possible workaround is to configure your monitors system-wide to match
KDE settings. Here is a possible way to do it:
https://forum.manjaro.org/t/dm-multi-monitor-configuration/99978
Now to the details. There are at least two mechanisms leading to this bug.
The first of them is the widget position rescaling that is intended to be
triggered by a resolution change when Plasma is running, but what actually
happens at startup is the following. Suppose we are switching a single screen
from a higher to a lower resolution. Initially, the widgets are laid out to
their saved positions from the config file which are based on the resolution
that should be set when Plasma is up and running. Then, upon a resolution
change, the previous AppletsLayout item size gets saved, which at that point
matches the whole previous resolution, and then, near the end of Plasma
startup, gets compared to the new size, which, aside from corresponding to a
different resolution, is further affected by the now loaded panels sizes
subtracted, and a rescaling is done. Now, if there are two monitors of
different resolution connected and the primary screen gets changed, which was
my actual initial case (although in my case the monitor arrangement was also
different), then the new and the saved layout sizes get swapped (and further
subtracted the panel heights), which is probably caused by ID mismatch in
(m_containment->screen() == id) comparison in appletslayout.cpp.
The second one happens when a resolution is changed from a lower one. In this
case, the window size and the AppletsLayout size don't change immediately after
the resolution changes. Actually, their sizes may stay equal to the old
resolution for several seconds. And the resizing itself may also be tricky,
involving reverting resizes and going through animation sequences. Initially,
the applets are correctly laid out to their saved coordinates, but then
m_configKeyChangeTimer gets activated and calls
m_layoutManager->resetLayoutFromConfig(), which repositions the widgets while
watching them not to fall out of the layout boundaries, which have not been
updated yet. Then the first mechanism comes in to make things even worse.
Rotating a screen basically triggers the same mechanism, the main difference
being that initially all the widgets are shown up as a mess in the corner
before setConfigKey is called.
All the testing was done on X11.
--
You are receiving this mail because:
You are watching all bug changes.
