ivan added a comment.
> This is like a step 1, right? It appears the requestAdd/Remove APIs > currently add/remove to all activities This is the first step that actually worked. Yes, the add/remove API will get a requestAdd/RemoveTo/FromCurrentActivity. > I'm a bit surprised that the code doesn't use the existing machinery to > filter the launcher list by activity ... couldn't LauncherTasksModel just implement This happens when someone goes into this blind. I'll see how to make it work with the current filtering mechanism. > Note that there shouldn't be any magic that only makes sense in concert > with the specific TM applet, the libtaskmanager There is nothing really magic here. Namely, the old API returned urls "serialized" as strings - it still returns serialized data. I don't see a way around this approach (I've tried having it separated, but then you have the problem of what is saved where, and how it should be synced) since the data model expects the client to provide the serialized data instead of providing, for example, a config group or some kind of ID for the model to have a full control of the storage. REPOSITORY rPLASMAWORKSPACE Plasma Workspace REVISION DETAIL https://phabricator.kde.org/D3005 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: ivan, #plasma, hein Cc: plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas
