https://bugs.kde.org/show_bug.cgi?id=520065
Marco Martin <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |FIXED Latest Commit| |https://invent.kde.org/plas | |ma/plasma-workspace/-/commi | |t/919a8a92a5c3437f6406a0970 | |c548ecf7100e439 --- Comment #7 from Marco Martin <[email protected]> --- Git commit 919a8a92a5c3437f6406a0970c548ecf7100e439 by Marco Martin. Committed on 14/05/2026 at 12:14. Pushed by mart into branch 'master'. Libtaskmanager: invalidate filter on source row insertion When a source row is inserted, is possible it's a row we have either a launcher or a startup entry existing, which will now need to be filtered out. previously it was emitting dataChanged on the source launcher or startup task, causing then a reevaluation of the filter. But since we still were in the rowsInserted handler, the state might have not been settled yet, so TaskManager::TaskGroupingProxyModel::Private::sourceDataChanged could find itself with an invalid source index, triggering an assert. Instead simply call invalidateFilter, which will cause all the filterAcceptsRow to be called again at the right moment. It is a bit more inefficient as the row iteration will be done for each entry instead of only as many times as there are new rows, but should be much safer. ### Test plan launch an app, the startup task should still change immediately to the "real" one as soon the window appears without the task being duplicated for a split second. same thing when starting a task from a launcher. ### Bugs fixed M +4 -33 libtaskmanager/tasksmodel.cpp https://invent.kde.org/plasma/plasma-workspace/-/commit/919a8a92a5c3437f6406a0970c548ecf7100e439 -- You are receiving this mail because: You are watching all bug changes.
