https://bugs.kde.org/show_bug.cgi?id=365617
Eike Hein <h...@kde.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDSINFO |UNCONFIRMED
Resolution|WAITINGFORINFO |---
--- Comment #19 from Eike Hein <h...@kde.org> ---
It's not that weird or surprising - the code works roughly like this:
1) Whenever a new launcher appears or data for an existing launcher changes,
the data model checks whether there are any windows for the same app, and if
there are, the launcher is filtered out, otherwise it is shown
2) Whenever a window is closed, the data model checks whether there are any
launchers for the same app, and if so, triggers a "the data for this launcher
changed", so that (1) runs again, implicitly now revealing a previously
filtered-out launcher
3) When the system binary cache of .desktop data changes (e.g. by touching a
filesystem location with .desktop stuff), the launcher data model reloads (e.g.
to update icons and titles), causing data change notifications, causing (1)
In other words it's obvious that (2) fails, but that's really odd because (2)
uses the same logic for "is this for the same app?" as (1), and (1) presumably
works for you (Chromium window replaces launcher). But then the window is
closed and the launcher is not re-revealed, i.e. (2) failed.
There was a bug causing (2) to fail under complicated circumstances (involving
two Task Managers and a particular instanciation order and state), but the fix
for that is in 5.7.2. According to the data you provided the "is this the same
app?" logic should also have no problem with the launcher or window. So for
now: No idea why it fails.
--
You are receiving this mail because:
You are watching all bug changes.
