TasksModel filters out matching launchers when a startup or window
appears. When they go, dataChanged in the launcher model is triggered
to pop them back in. This used to be in response to
rowsAboutToBeRemoved, with a Qt::QueuedConnection to try and make sure
that dataChanged is emitted after the row removal is processed (other-
wise the filter would still take). While I have not been able to
reproduce the bug well enough to test things, my guess is that this
must be a race condition - perhaps something is spinning the event
loop.
This patch collects the indices in the handler for sourceModel::
rowsAboutToBeRemoved and triggers dataChanged for them in the handler
for ourselves::rowsRemoved. Keeping model indices around is usually a
huge red flag. This makes the (currently solid) assumption that nothing
will change the launchers model inbetween the halves of this transaction.
BUG:365617