https://bugs.kde.org/show_bug.cgi?id=379414
--- Comment #4 from Eike Hein <h...@kde.org> --- 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. -- You are receiving this mail because: You are watching all bug changes.
