https://bugs.kde.org/show_bug.cgi?id=383017
--- Comment #6 from Eike Hein <h...@kde.org> --- This isn't really a regression (and frankly not really that much of a bug, and low-priority as it's an edge case of a fallback codepath). Basically, the data model internally keeps a cache of information about the application owning a window. Which application that is is figured out based on window metadata. When relevant window metadata changes, the cache is wiped; the next request for data from the model will rebuild the cache from scratch, running the app identification heuristic in the process. If a request for the icon comes into the model, it asks for the icon from cache. If the cache doesn't yield an icon, it asks the window manager instead as a fallback - and adds the icon into the cache so it can be found there next time. In other words, if the cache is wiped due to a metadata change, the WM will be asked again for the icon when the UI frontend decides it needs it. This explains why you see the icon change "sometimes": The metadata changes causing cache evictions are unrelated to the icon and just evict the icon as a side-effect (WM icon changes are not monitored as relevant metadata), and when exactly the UI frontend asks again for the icon is also situationally complex (e.g. when recreating delegates, or in cases where the model tells it to re-request /all/ data for a task). The way to fix this is to keep track of which windows currently have their icon provided by the WM fallback, and monitor WM icon metadata changes for those windows until the fallback is no longer needed (which could happen if a window fixes its metadata at runtime so the app matching heuristic succeeds, or the app is (re-)installed correctly on the system and can now be found). This should be done, but the priority is usually to find out why a window hits this fallback path in the first place and fix the app/install. -- You are receiving this mail because: You are watching all bug changes.
