Created attachment 126099 [details] gif showing the described phenomenon. Thunderbird icon has 1 new message, panel is hidden, email is read, panel is shown again. SUMMARY Visual changes to widgets are only applied when the panel is visible STEPS TO REPRODUCE 1. set a panel to auto-hide 2. let it hide 3. trigger a change in some widget, i.e. close a task or acknowledge a notification that is visible on a systray icon. OBSERVED RESULT On the next time the panel is visible, the changes will be applied, the task manager will quickly remove the ask change sort/layout, the systray icon will quickly remove its notification. EXPECTED RESULT When showing the panel, the widgets should show the current state, not the state when it was last visible + transitions to the current state. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Kubuntu 18.04 LTS KDE Plasma Version: 5.12.9 KDE Frameworks Version: 5.44.0 Qt Version: 5.9.5
I think this is by design, so it doesn't needlessly re-render when it's not visible.
(In reply to Kai Uwe Broulik from comment #1) > I think this is by design, so it doesn't needlessly re-render when it's not > visible. That makes sense, yes. It crossed my mind as well, but I'm not anywhere close to knowledgeable enough to confirm it. Could be an optional setting, if that's easy to implement. I'd happily trade a bit of performance for keeping my attention focused, but if I were limited by HW constraints, that would likely change.
We're not going to add a setting. But we probably don't need to. Updating an icon doesn't require a re-render, and we always render once on the first expose. >the task manager will quickly remove the ask change sort/layout, the systray icon will quickly remove its notification. I don't know what this means.
(In reply to David Edmundson from comment #3) > >the task manager will quickly remove the ask change sort/layout, the systray icon will quickly remove its notification. > > I don't know what this means. When the current state does not match the state when the panel (and therefore the widget) was last visible, making the panel visible will initially show the previous state and then quickly update it to match the current state, e.g. the task manager widget will visually remove the task that was closed while the panel was hidden, a systray icon that showed a notification will be updated to reflect the current state. I've attached a gif to explain what I mean, where you can see the panel being shown (I had marked an email as read while the panel was hidden) and the red 1 quickly changes to the normal Thunderbird icon to reflect the current state of the icon, but it only does so when the panel is visible.
Seems more like a bug in IconItem rather than anything to do with Taskmanager. That does all sorts of things with icon visibility which I'm not sure are right.
Created attachment 126102 [details] Task manager removing item & reshuffling items when panel is made visible
(In reply to David Edmundson from comment #5) > Seems more like a bug in IconItem rather than anything to do with > Taskmanager. > Sorry for spamming, didn't know where the comment would end up that I was able to add when adding an attachment. I've added another gif to show what I meant regarding the task manager. When the panel was hidden, I closed one of the tasks. When it was visible again, the task was removed and the task manager widget reacted by switching to one-row-mode.
Can confirm the task manager issue in Plasma 5.26.1 and I also know it's an issue in 5.27.
Cannot reproduce in Plasma 6 following the port to use Kirigami.Icon; assuming it was fixed by that!
(In reply to Nate Graham from comment #9) > Cannot reproduce in Plasma 6 following the port to use Kirigami.Icon; > assuming it was fixed by that! I don't think this bug should have been closed yet. I'm still able to reproduce the bug, even on latest git tip ("KDE Plasma 6.1 Dev"). Could you retry reproducing using the following updated steps? STEPS TO REPRODUCE (slightly tweaked & incredibly pedantic): 1. Let's first make sure that noticing the problem will be as easy as possible: 1.1. Right-click an empty spot on the panel / task manager -> "Show alternatives..." -> choose "Task Manager" (classic taskbar-style) 1.2. Right-click the same spot again -> "Configure Task Manager..." -> Behavior -> Group: -> "Do not group" 1.3. System Settings -> General Behavior -> Animation Speed to something slower than "Instant" to exaggerate the problem 2. Set the panel to auto-hide ("Show Panel Configuration" -> "Auto hide") 3. Open 5 Konsole windows (close all other windows) 4. Press the Super key to show the auto-hidden panel 5. Let the panel auto-hide and close 2 Konsole windows (so that only 3 Konsole windows remain) 6. Stare at the bottom of the screen where the panel will soon reappear -> still keep looking there while pressing Super again WHAT HAPPENS: - first, the Task Manager briefly shows the previous state (5 Konsole windows open) - only after that, the state updates to -> 3 Konsole windows (there's a distracting and unnecessary animation) EXPECTED: Immediately show the correct state (3 Konsole windows open), i.e. don't (re)shuffle anything first for no reason
Created attachment 166103 [details] Screen recording that highlights the problem (animated GIF: following the slightly tweaked steps above)
Ah, I see what you mean now. Can still reproduce it, then.
(In reply to Nate Graham from comment #12) > Ah, I see what you mean now. Can still reproduce it, then. Great, thanks. This is definitely my biggest Plasma pet peeve, and it drives me bonkers. PS. Was changing the severity from minor to wishlist a "downgrade" or an "upgrade"? And if the severity is now even lower, could you please reconsider? Surely it is a bona fide bug (i.e. not the intended behavior) that when the user unhides the panel, it initially flashes a seemingly random state from the past (!?), followed by a gratuitous animation, and only then is "the truth revealed" by showing the actual current state? I've never seen a glitch like this anywhere else (macOS, Windows, Xfce, or any other panel I've tried that supports auto-hiding)
It's a downgrade, unfortunately. This reflects the fact that the issue is not a bug, but rather an undesirable quirk of the intended current design. To change it, we need to change the current design to do something we didn't originally intend it to do. That makes it a "wishlist" thing. This doesn't mean it will never get done, though!