Changing the launcher, the favorites return to the default Reproducible: Always Steps to Reproduce: 1. Change to an alternative launcher Actual Results: 1. favorites lost Expected Results: 1. favorites keep the same
Those are completely separate applets. I'm not sure just looping through configs from one plasmoid to another is a particularly good idea, especially since they don't neccessarily use the same format, could be a 3rd party applet, too. Confirming for now as it's a legitimate bug nonetheless imho.
so maybe there should be a common config for favorites, or be separated from the applets.
It's not just about favorites, any setting is lost; so even if you switch to one applet to try it and switch back you still have lost its settings :/
Is it possible to do a datasource for favorites? It doesn't have to be a different config for all applets, they would all fetch from this single data source.
There actually were plans couple of months back to have favorites globally stored in Activities but that was reverted again before it shipped, I think this [1] is it. [1] https://git.reviewboard.kde.org/r/119515/
*** Bug 352508 has been marked as a duplicate of this bug. ***
Having reported the somehow relevant bug 352508, I would like to say that I have thought specifically about sharing favorites between launchers and I would not agree in many cases. For example, Application Menus and Application Dashboard both have a lot of space for favorite applications, so they could share their settings, but Application Laucher has space for about six favorites, so sharing them with the other would probably not be convenient. I would propose that when switching to an alternative launcher the user could be asked to preserve (transfer) the favorites to the new one.
Since I personally don't think sharing favorites between launchers is a good idea either (see also past discussion on plasma-devel), I like the idea of tying it more to the activity of swapping one instance for the other.
I already made it transfer the global shortcut from the old applet to the new one when switching applets, perhaps we should move the config too? However, this might introduce strange side-effects. Or otherwise we add some kcfg flag that says "this entry can be migrated" and have the favorites be copied over?
We could also add a white list to the applet .desktop file. Question is how hi-res that white list would have to be (just config key name vs. that and data type vs. that and known applet names) and whether we really want to go down the road of making applets aware of each other's config representation along with running the risk of false positives. The alternative is still special-casing favorites data and having an API for it (e.g. like the proposal of delegating favorites storage to KActivities), but making that API support instance sharding and explicit migration between shards.
*** Bug 355785 has been marked as a duplicate of this bug. ***
plasma 5.11 solved this issue.