https://bugs.kde.org/show_bug.cgi?id=527651
cwo <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Latest Commit|https://invent.kde.org/plas |https://invent.kde.org/plas |ma/plasma-workspace/-/commi |ma/plasma-workspace/-/commi |t/61696f10c1624d25d290a9582 |t/043e4bfbce8131ca3ef1f20c6 |cb3c1c4e2c21088 |f3200a2c4e04035 --- Comment #13 from cwo <[email protected]> --- Git commit 043e4bfbce8131ca3ef1f20c6f3200a2c4e04035 by Christoph Wolk. Committed on 26/10/2026 at 14:31. Pushed by cwo into branch 'Plasma/6.8'. applets/kicker: port old favoriteId format to new one A long time ago, the format for the id application favorites that's stored in the kactivities database was changed from bare .desktop file names to applications: urls. Recently, we also ported away from the final bits and unified the internal ids used in the kicker backend to this format, rather than constantly converting between them and introducing weird bugs when the formats did not match. Now that we use the same id internally, there's nothing that should still add the old-style ids, or so I thought... As it turns out, there is at least one edge case where old-style urls can still be introduced to the database, and that is our mechanism for setting default favorites. If we add an application that we can't find a KService for, we can't normalize the id, and so fall back to taking the value as is and saving that as an (absent) favorite. In most cases, that is a bare id with no url scheme. If the app is later installed, kicker gets really confused and lists it among the favorites, but doesn't consider it a favorite on any activity, and any attempt to change its state will fail. Long-term, we really need a better mechanism here - the whole "secret favorites that are in the database but will only show up once installed" bit is confusing and probably not exactly a great UX either. But we support a lot of formats for specifying default favorites, which makes correct identification difficult, and allow distributions and deployments to override our defaults (and should not break their setup) There may be even legitimate cases for application favorites that don't exist during initial startup (e.g. on an unavailable network share?). So we should tread carefully here. In the mean time, we should at least fix the breakage, and convert the old-style favorite ids to new one. Luckily, this is pretty much an edge case that will mostly apply to experts doing a very custom plasma install, and the number of default favorites should generally be quite small. We can fix the issue similar to the old migration code in 19f046e1cfaa9b088899124291392e976cf59e04: checking whether this problem applies, then removing the old favorite and adding the new one. (the implementation has to be slightly different, and we try some extra handling to try to maintain the favorite order and any specific activity setup that the user may have made, though I wouldn't have an idea how). This fixes the issue, and I hope without messing up the order of favorites in the launcher (but can't 100% guarantee it, as this is very complex and much happens asynchronously). (cherry picked from commit 61696f10c1624d25d290a9582cb3c1c4e2c21088) Co-authored-by: Christoph Wolk <[email protected]> M +20 -0 applets/kicker/kastatsfavoritesmodel.cpp https://invent.kde.org/plasma/plasma-workspace/-/commit/043e4bfbce8131ca3ef1f20c6f3200a2c4e04035 -- You are receiving this mail because: You are watching all bug changes.
