Bug 351553

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