Some windows have their task appearing below the launchers and the other tasks in the new Task Manager in Plasma 5.7 Beta, see screenshot for visual description. I put a red rectangle around the task so that you can localize it. Restarting plasmashell usually fixes the problem. The Task Manager is configured to allow only one line of tasks. Reproducible: Sometimes Steps to Reproduce: 1. Open several windows 2. Look at Task Manager : sometimes a window goes all the way down 3.
Created attachment 99624 [details] Screenshot of the problem
Can you provide any more clues on the circumstances this happens in, such as: - Number of launchers - Number of tasks - Number of tasks corresponding to pinned launchers - How full the bar is - Sequence of events To fix it we need to reproduce it, and so far no luck :)
Actually I most likely found it in auditing now.
It happens when there are 4 or more windows open in the task bar (when the tasks have to shrink to let the new ones appear on the panel). It happens only with the 4th task, which means that if I open a fifth application, this 5th application appears correctly on the task bar. Example : - I have 3 windows open : Akregator - Fiefox - Dolphin - I open a fourth one : konsole : it goes below like on the screenshot - I open Systemsettings : it appears correctly on the task bar next to Akregator, Firefox and Dolphin ; Konsole is still hiding below - I close Dolphin : Konsole stays below the others I have 4 launchers ; wether the tasks are pinned launchers or not does not seem to have an impact.
Git commit fb2689b22de8fd7abf3690f7cdb01d7cf9983b0e by Eike Hein. Committed on 21/06/2016 at 07:54. Pushed by hein into branch 'Plasma/5.7'. Invalidate cached launcher count also when the source model changes. When a launcher was removed, the cache was invalidated at the time the top-level proxy removes the row for it. However this happens in response to rowsAboutToBeRemoved from the source model, at which time launcherList() still contains the launcher at the row about to be removed. While invalidating the cache in response to rows being removed from the top-level proxy is correct (for the case where a window task shadowing a launcher is removed), to handle a launcher removal we also need to invalidate it when the launcher list changes. M +2 -0 libtaskmanager/tasksmodel.cpp http://commits.kde.org/plasma-workspace/fb2689b22de8fd7abf3690f7cdb01d7cf9983b0e
Git commit 69306414ffc0a68256fab73467130e69c89d3370 by Eike Hein. Committed on 21/06/2016 at 08:09. Pushed by hein into branch 'master'. Do a layout pass when TasksModel.launcherCount changes. It can change independently of the repeater adding/removing items. M +2 -0 applets/taskmanager/package/contents/ui/main.qml http://commits.kde.org/plasma-desktop/69306414ffc0a68256fab73467130e69c89d3370
Git commit b9c0aa37294189da4589a0f47d97ab9a73b9c89a by Eike Hein. Committed on 21/06/2016 at 08:11. Pushed by hein into branch 'Plasma/5.7'. Do a layout pass when TasksModel.launcherCount changes. It can change independently of the repeater adding/removing items. M +2 -0 applets/taskmanager/package/contents/ui/main.qml http://commits.kde.org/plasma-desktop/b9c0aa37294189da4589a0f47d97ab9a73b9c89a
An additional information : I removed my old Plasma configuration to start with a fresh one and the bug did not occur since then.