Created attachment 105084 [details] Picture of List of alternative Launchers After Upgrade to Kubuntu 17.04, Application Launcher Favourites are lost after a "Switch" between the different Launcher menu types. 1) Create some Favourites in the Menu. (Right-click "Add to Favourites") 2) Right Click on the K Start Button 3) Choose "Alternatives..." 4) See the list of alternative menus. 5) I have "Application Launcher", "Application Menu"(default) and Application Dashboard" See Attached JPEG 6) Select a different one from before (any) 7) See the Favourites. Note, new ones are missing. Not OK.
This isn't a bug. Different applet instances have different configuration. Using Alternatives is the same as removing and adding an applet. The different applets don't know anything about each other, so they don't know some have favorites and some don't. That said, in Plasma 5.11 (probably) we'll be moving to a system where favorites can be stored in the Activities database and launchers are encouraged to use that global (per-activity) storage for favorites. They will then share them when they do.
Re Comment 1, This is a bug. Switching applets should not delete all favourites. 1) Create favourites in any applet. 2) Switch to another applet. 3) Switch back. See the newly created favourites are lost. It doesnt matter where they are created they are lost after a switch. Maybe they are deleted by the switching? If it was as you say in Comment 1, you could have different sets of favourites. This is not the case.
Of course you can have different sets of favorites. You can have as many instances of any of the applets as you wish.
Well this is "not possible" for me. I'd like to fix it. Maybe it's failing for others too?
I think you just misunderstood my comment or are otherwise confused somehow ... could you give it a re-read and then explain again what problem remains that I didn't address? Sorry, I am lost.
Yes, you say the applets (currently) manage favourites separately. Which is OK. However the phenomenon I have, is that these favourites are being 'deleted' when the "Switch" operation happens. 1) Create favourites in Applet 1. = OK. These favourites are saved. 2) Switch to Applet 2. 3) Switch back to Applet 1 again. 4) See those new favourites are not there. = NOK.
See comment 1 - this is expected behavior. Different applets, and different instances of the same applet, currently don't share configuration in any way, it's always seperate. "Application Menu" doesn't know anything about "Application Dashboard" and vice-versa. They don't know they both have a favorites feature (what if you installed and switched to a menu applet that doesn't?). They have no access to each other's config, so they can't copy anything. I also explained in the second paragraph that there's changes on the way to this, in the form of a global favorites db that applets can use in the future (and the default bundled ones will).
Thanks. It's good that there is a fix in the pipeline. And you explained a "reason" it currently fails to behave according to usability expectations. But from the users point of view it is clearly a bug when my work gets lost without warning.
Maybe, although that's the user expectation being wrong because they don't understand the system - there's really no reason to expect config to migrate between entirely seperate applet instances. I.e. the bug there would be missing onboarding/teaching people how things work.
Ah. Now we're getting into quality of usability. And what a user should be expected to know, in order to use a desktop environment. Working in ergonomics, I like to treat users as guests. And treat such bugs/problems as important to make the overall experience consistent. Without surprises or needing to learn too much. In this case we don't expect "config to migrate between entirely seperate applet instances". They can stay isolated. But not get 'deleted' like they are here. Deleting is a bug.
Well, we're aware that users want launchers to share favorites and store them independently of particular launcher instances ... hence the work underway, which you can follow in https://phabricator.kde.org/D3805 btw,
See also bug 341246 and bug 189852.