The issue is the following: 1. add the icon-only taskmanager in the panel 2. add two launchers that are available to all activities 3. add a third launcher which is only available in the current running activity 4. go to another activity 5. add a new launcher which is only available in the new current running activity 6. after that move between these two activities and just try to change the order of the launchers, at some point the user can notice that the explicit assigned launchers are lost ---- following the code also through Latte what is happening is the following... many times when changing the order of the launchers the launcherList returned from the taskModel is the (global launchers + the current activity launchers), all the rest are dismissed (this is checked for the running one activities but it could be also and for the not running ones)... This creates data loss for the user
I'm currently on a Wayland-focused Plasma dev sprint, but I'll try to look into this at some point this month. Sorry for delays.
on prob Eike... It probably influences both plasma 5.9 and 5.10
Confirming also for the normal task manager. I'll try to find what broke.
Basically the reason is that the data round trip is broken between the model and the applet. The launcherList() getter returns a list built from d->launchersOrder, but the setLauncherList() setter builds a new d->launchersOrder from what's passed in, and on a move(), the applet passes in a new list based on what it sees after filtering by activity. The result is that the launchers specific to activities other than the current activity get dropped. The change signal is emitted, and a new list from the getter sans them is written to the config. To sum it up, if you have activity-specific launchers on an activity different from the current one, reordering launchers in the currenty activity will remove them. This is not a regression in this dev cycle, this bug was introduced with per-activity launchers in 5.9.0 and is a design oversight in the code. We can't make setLauncherList() implicitly activity-specific because we need a setter for the full list to reload it from config. We need a setLauncherListCurrentActivity() that's smart enough to do a merge. Ivan, can you write this? You solved the same problem for Kicker-based launchers so you presumably have a preferred way now. I'd like to see consistent behavior between the interfaces, if possible/desirable, and I'm not exactly sure what policy decisions you made on the launcher menus side for this case.
BTW: Keep in mind 5.10 final tagging is soon; while this is not a regression it is serious and I'd like to see it addressed it in that release still, if possible.
I'll see what can be done. The sad part is that the pinned tasks is a completely different beast to kicker favs. (here we chose to have different per-applet pinned things, not global, so it does not use activity linking at all)
Fixed in the commit e8e2be90834b6526006f4961d62d511079d24d26 (for 5.10)
(In reply to Ivan Čukić from comment #7) > Fixed in the commit e8e2be90834b6526006f4961d62d511079d24d26 (for 5.10) just a little note, the fix changes a bit the launchers ordering in some cases. If I read correctly the code the patch adds the non active launchers(that are hidden) after the active state launchers (launchers that are currently shown). So when the user moves the launchers for various activities will always end up in the following ordering: [global launchers] + [activity specific launchers] if the user adds a global launcher after the [activity specific] launchers after moving the launchers in other activities he will end up with the above ordering. Being honest, no problem, I prefer it that way