https://bugs.kde.org/show_bug.cgi?id=506562
David Edmundson <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Latest Commit|https://invent.kde.org/plas |https://invent.kde.org/plas |ma/plasma-workspace/-/merge |ma/plasma-workspace/-/commi |_requests/6879 |t/4a513cce1d320e368c665e54f | |a9aaf5307d11254 Resolution|--- |FIXED --- Comment #26 from David Edmundson <[email protected]> --- Git commit 4a513cce1d320e368c665e54fa9aaf5307d11254 by David Edmundson. Committed on 28/09/2026 at 08:51. Pushed by davidedmundson into branch 'master'. Fix the window mapping again The idea of the current code is we have: - a launcher model - a startup model - a window model we then: - concatenate these models - then filter them - then group them - then filter some out again in TasksModel This last part is a bit sketchy. There is a goal that is if a launcher exists for a window that is showing we should hide the launcher. It's an unusual pattern for a filter model, when entry B gets inserted, entry A should get removed. The current code detects when a launcher is added, then emits dataChanged in the filter model. Emitting dataChanged in another model is very weird, we end up recursively getting back into dataChanged handling from within a call handling dataChanged and the mapping gets mangled. Instead lets keep filtering in the filter model and avoid this incorrect dataChanged to trigger a re-evaluation. We do it directly when the source changes. M +58 -0 libtaskmanager/taskfilterproxymodel.cpp M +14 -0 libtaskmanager/taskfilterproxymodel.h M +5 -92 libtaskmanager/tasksmodel.cpp https://invent.kde.org/plasma/plasma-workspace/-/commit/4a513cce1d320e368c665e54fa9aaf5307d11254 -- You are receiving this mail because: You are watching all bug changes.
