this is an upgrade scenario akin to bug #351550 Favs are presently identified by their desktop file name. So for example kontact.desktop would be tracked as kontact and then looked up again as kontact -> kontact.desktop. When the desktop file name changes as part of an upgrade, then kickoff is no longer able to map kontact -> kontact.desktop and thus the fav entry breaks. This is a particular pressing issue right now as applications (including 3rd party) are slowly moving to an appstream like naming scheme with a RDN.appname naming which pretty much lets us expect that every somewhat major upgrade (be it a new kde applications release or a new distro release) will break fav entries for someone. I would imagine that the only way to somehwat accurately handle this is implement a fallback mechanic. Namely I'd suggest: a) store the Exec entry of the desktop file of a favorite along with the desktop name b) if a favorite cannot be found: - try to find it as .+\.appname\.desktop - if more than one desktop file is found to match, check if Exec matches with what we expect - if Exec doesn't match entirely strip argument placeholders and check if it matches - if no desktop files were found to be matching or Exec doesn't add up: look through all desktop files employing the Exec check to find a suitable candidate - give up if even crawling all desktop files doesn't yield a single suitable result (for a) it might actually be reasonable to simply draw a copy of the desktop file upon creation and update it ever so often. that way one can easily expand the matching algorithm later by adding a match on name for example) Reproducible: Always
Ah, actually. kickoffrc stores the actual file path to the favorite not just the basename. Doesn't change anything though.
This was fixed by porting Kickoff to the Kicker backend.