I have two displays, the primary is a 3840x2160 display and the secondary is a 1920x1080 display that is configured as an extension to the right of the primary display. The primary display has two horizontal panels, on the top and bottom edge of the screen. No other widgets on the desktop. 1. Unlock widgets and add a Calendar widget on the top right corner of the primary display. Resize the widget so that the calendar grid is visible. 2. Reboot. 3. After the reboot the Calendar widget position is changed. It is now placed in the top right corner of the top left quarter of the primary screen. Widget position should be preserved across reboot. This is a regression in Kubuntu 18.04, the position did save in 17.10.
Created attachment 112427 [details] Screenshot before reboot
Created attachment 112428 [details] Screenshot after reboot
This is very likely a dup of (my) bug #389141, filed back when the problem was probably still in unreleased live-git only. Unfortunately it wasn't fixed, tho I can't say my bug report was as good a quality as I'd have liked and I never did get the bisect done I wanted to do. I too have two displays, one a 4k/3840x2160, the other a full-hd/1920x1080. Tho in my case the problem appeared after the screen-blanker activated (no lockscreen configured) and the monitors, having no signal any longer, automatically turned off, when I turned them back on -- no actual need to logout/reboot. Another difference, my higher-res 4k primary is to the right of the full-hd secondary, while in your case it's to the left. But an additional behavior detail I noticed after I filed the bug, that I had been meaning to add, that from your screenshots applies in your case to: Plasmashell is apparently mistakenly repositioning the widget to conform to the lower full-hd resolution of the /other/ monitor in an effort to keep it in-frame/on-monitor, failing to account for the larger 4k resolution of the monitor it's actually on. With the monitor-relative 0,0 origin at top-left and the 4k monitor being twice the resolution of the smaller one in each direction, the top-left quadrant is the monitor-relative size and position of the smaller monitor, so the repositioning is into it. Thus, anything outside the top-left quadrant will be repositioned into it, while anything in it should stay where it is. Hopefully with this additional description of the apparent repositioning trigger for the bug we're both seeing, they can figure out what's going wrong and patch it. =:^) Meanwhile, here's a workaround (assuming you can't just put your widgets into the top-left quadrant as a workaround) that I've been using here that should help: Find the plasma-org.kde.plasma.desktop-appletsrc file in your config (my settings are customized but check in ~/.config and its subdirs) and set it read-only when it has the correct config (as it should if you setup the widgets as you want and then killall plasmashell, you can restart it again from krunner after setting the file readonly). That should prevent the bad positioning from being written to the file, but note that you'll need to set it writable again to make other changes to your widgets and panels or most of them (the ones saved in that file) won't save either. With the file set read-only, I'm not sure if plasma will set the correct position at bootup/login, it may depend on the monitor detection and setup sequence as plasma starts up, but if not you can always killall plasmashell and restart it again, and it should then load the correct config.
*** Bug 389141 has been marked as a duplicate of this bug. ***
I has encountered the same issue. In my case, the primary display is 90 degrees rotated (1200*1920) and the second one is on its right. Please reference attached displaysetting.png I placed a widget in the lower-left corner of the primary display. Every time the computer reboots, the widget will be placed to the middle of the left edge and I have to drag the widget again. Maybe it is because the widget is rendered or position recalculated before applying the rotation during the startup? The issue is a bit annoying. I am trying to find a way to move the widget through command line so I can schedule it at the startup, avoiding manually drag the widget every time. Using the API from https://userbase.kde.org/KDE_System_Administration/PlasmaDesktopScripting#API , I can only modify the widget position in the plasma-org.kde.plasma.desktop-appletsrc file. Any help is appreciated.
Created attachment 113531 [details] display setting
I think I has encountered the same issue (although there is only 1 display). After several hard shutdowns of my PC and reboots (because the screen is going on and off, looks like other issue), the default panel disappeared. Firstly I tried to add it. Any widget I added show the number 2 on it, like it's the second time I am adding this. So, it looks like the original panel still somewhere ("off-screen"?).
Created attachment 114350 [details] plasmashellrc file
Created attachment 114351 [details] plasma-org.kde.plasma.desktop-appletsrc file
1. My system: Kubuntu 18.04.1 64bit KDE Plasma 5.12.6 2. After some additional searching, I am wondering if my/this issue related to bug 360478?
Plasma has general problem with saving settings. Read my comments: https://bugs.kde.org/show_bug.cgi?id=356899
I have this bug as well but only when the KDE connect application generates popup notifications on login. That is if my phone has unread notifications from email, voicemail, SMS or another messaging app then those notifications will popup on the desktop in the top right as soon as I login. When this happens two widgets located on the top right and mid right are re positioned. When my phone is not connected to the network the widgets appear in their proper place. Distro: KDE Neon Bionic (preview version Aug 8th 2018) Plasma: 5.13.4 Frameworks: 5.49.0 Qt: 5.11.1 Kernel: 4.18.4-041804-generic
I'm experiencing this bug since I've switched from 2 DVI monitor to 2 DP monitor with daisy chain (Nvidia drivers).
*** Bug 393270 has been marked as a duplicate of this bug. ***
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.
*** This bug has been marked as a duplicate of bug 413645 ***