SUMMARY Plasma 6.3 was promised to remedy the problem of the plasma (not full width) at startup didn't appear right. And as far as the bottom panel concern this is true. But my autohiding, not full-width top panel (global menu and sytem tray) still doesn't at all. STEPS TO REPRODUCE 1. start plasma 2. wait a while 3. bump cursor to the top of the screen OBSERVED RESULT Nothing happens EXPECTED RESULT Auto hiding panel (centered) would appear Operating System: KDE neon 6.2 KDE Plasma Version: 6.3.0 KDE Frameworks Version: 6.10.0 Qt Version: 6.8.2 Kernel Version: 6.11.0-17-generic (64-bit) Graphics Platform: Wayland Processors: 4 × Intel® Core™ i5-6300U CPU @ 2.40GHz Memory: 7.6 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 520 Manufacturer: Dell Inc. Product Name: Latitude 5480
Oh, and just as before: entering edit-mode makes it right.
Assuming you're referring to Bug 489086, what you're describing here sounds like a different problem. Can you attach a screen recording that shows the issue happening, and also write steps to reproduce that indicate how to set up a panel in such a manner that makes the problem appear? Thanks!
I tested this on 6.3.0 and git-master. I'm not able to reproduce, even after a few days with this setup On 6.3.0 I have it under a global menu bar, on the other there is no other panel at the top. Both always show with mouseover. Panel creation: - Default panel on the bottom - Add top panel with width set to fit content, centered, and autohide
I'm not so successful with my screenrecordings... But on my system (plasma 6.3.0 neon user edition) the bottom panel - dodge windows - always appears after startup but the top one - set to fit content, centered, and autohide - very often doesn't. When I also make the top-panel dodge windows, then it's totally reliable. But on my system the auto-hide makes it unreliable. With autohide I have to enter edit-mode to call the top panel Even after I removed the top-panel and created it again. I'm curious if plasma 6.3.1 will make it better. I will inform you on this place.
I found it! So I have a top panel with in it: - digital clock widget, system tray, weather widget and global menu widget. This top panel "fits content" and is autohiding. After the start of the system it seems as if I can't "call" the top-panel by bumping the top of the screen. But after a lot of experimenting I found what is wrong... The autohiding top-panel has "no feeling" after systemstart. Only in the exact middle of the top it feels the cursor. You have to touch a very narrow area in the middle the first time (not more than one centimeter). Once it has appeared after you touch the exact right place then the top panel "feels" the cursor over the full width of the panel.
Ah! In fact that's intentional right now, because it's possible to have multiple auto-hiding panels on the same screen edge, so each panel needs its own activation zone; it can't use the entire screen edge. *** This bug has been marked as a duplicate of bug 464856 ***
I read the bug 464856 - Non-maximized auto-hidden Panel should un-hide when cursor moves to any part of its screen edge, not just the part of the edge that's over the panel - and that bug is really not the same story as mine here. Direct after startup of the plasma system - the very first time I "call" this panel - the area where the auto-hidden panel is sensitive is no wider than my pinky nail. After you have touched this very small zone and the panel has appeared one time, then the sensitive zone is just as wide as the panel. If only directly after the startup of Plasma the sensitive zone of the panel had the same width as the panel! I could live very well with that!
(In reply to PK from comment #7) > If only directly after the startup of Plasma the sensitive zone of the panel > had the same width as the panel! > I could live very well with that! Wait and see if the resolution to bug 499914 fixes this - there seems to be an issue with flexible-width panels not updating their size in response to changes right now. I don't know if this is the case, but the fix should likely be in 6.3.2 and we can revisit the issue after that.
I have plasma 6.3.2. on my system now but the bug is still present.
In progress with https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/5233
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/5313
(In reply to Bug Janitor Service from comment #11) > A possibly relevant merge request was started @ > https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/5313 Do I read correctly that the fix is included in Plasma 6.4? In that case we will have to wait a little. Or should there be written 6.3.4?
Git commit 14e84ee06899e63a0c64d50bd1ab329a16aad533 by Niccolò Venerandi. Committed on 13/03/2025 at 20:12. Pushed by niccolove into branch 'master'. Check for queued positionAndResize requests at the end of the event cycle Otherwise, calls might be queued during an update, and only be acted upon when the successive update is called instead of during the next frame. Related: bug 499914 M +4 -5 shell/panelview.cpp https://invent.kde.org/plasma/plasma-workspace/-/commit/14e84ee06899e63a0c64d50bd1ab329a16aad533
Git commit 4151038ae6556d99f45297d3f722c60a55389073 by Niccolò Venerandi. Committed on 13/03/2025 at 20:14. Pushed by niccolove into branch 'Plasma/6.3'. Check for queued positionAndResize requests at the end of the event cycle Otherwise, calls might be queued during an update, and only be acted upon when the successive update is called instead of during the next frame. Related: bug 499914 (cherry picked from commit 14e84ee06899e63a0c64d50bd1ab329a16aad533) Co-authored-by: Niccolò Venerandi <niccolo@venerandi.com> M +4 -5 shell/panelview.cpp https://invent.kde.org/plasma/plasma-workspace/-/commit/4151038ae6556d99f45297d3f722c60a55389073
Grr, this is still broken. Reason is that when the panel is hidden, update() does not seem to create any update event. Solution is not to do any queueing when panel is hidden, but there's no way to know if a panel is hidden. Need to implement that
(In reply to Niccolò Venerandi from comment #15) > Grr, this is still broken. Reason is that when the panel is hidden, update() > does not seem to create any update event. Solution is not to do any queueing > when panel is hidden, but there's no way to know if a panel is hidden. Need > to implement that wonder if what happens in update should happen instead in an own qtimer-activated function
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/5319
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/5328
Git commit ef670e91f10f30cec95113500e981a8a2cb9a87d by Niccolò Venerandi. Committed on 23/03/2025 at 17:43. Pushed by niccolove into branch 'master'. Only queue position updates for panel when not hidden Since update events are not propagated when the panel is hidden, we do not rely on those to queue position updates. Instead, we immediately resize the panel. M +7 -3 shell/panelview.cpp https://invent.kde.org/plasma/plasma-workspace/-/commit/ef670e91f10f30cec95113500e981a8a2cb9a87d
Git commit 6a64e787235c9379280b15c017b7904ec5bf1fe2 by Niccolò Venerandi. Committed on 23/03/2025 at 17:44. Pushed by niccolove into branch 'Plasma/6.3'. Only queue position updates for panel when not hidden Since update events are not propagated when the panel is hidden, we do not rely on those to queue position updates. Instead, we immediately resize the panel. (cherry picked from commit ef670e91f10f30cec95113500e981a8a2cb9a87d) ef670e91 Only queue position updates for panel when not hidden Co-authored-by: Niccolò Venerandi <niccolo@venerandi.com> M +7 -3 shell/panelview.cpp https://invent.kde.org/plasma/plasma-workspace/-/commit/6a64e787235c9379280b15c017b7904ec5bf1fe2