- The URL in the configuration file now contains also the list of activities it should be shown in
- The configuration format is backwards compatible
- Added API to differentiate between the shown launchers (for the current activity), and all configured launchers
- Supports reordering of the launchers
Details
- Reviewers
hein - Group Reviewers
Plasma - Commits
- R871:060681d69479: Relying on the filter model to do the filtering
R120:68a490c9fd01: Library support for per-activity pinned tasks
R871:ce5d187f4340: Removed debugging output
R120:3de821de2756: Exporting activities list through data member function
R871:b4a8f6c6454c: Validating the list of activities specified for a launcher
R120:d20ad165142c: When a launcher is on all activities, the list is now empty
R120:060681d69479: Relying on the filter model to do the filtering
R120:ce5d187f4340: Removed debugging output
R871:3de821de2756: Exporting activities list through data member function
R120:8bb1058194a6: Nicer handling of duplicate urls
R871:8bb1058194a6: Nicer handling of duplicate urls
R871:a5e92b3ca11c: Filtering now checks for the null activity
R871:d20ad165142c: When a launcher is on all activities, the list is now empty
R871:68a490c9fd01: Library support for per-activity pinned tasks
R120:a5e92b3ca11c: Filtering now checks for the null activity
R120:b4a8f6c6454c: Validating the list of activities specified for a launcher
- It needs the ivan/per-activity-launchers branch of plasma-workspace because of the API changes. At the moment, the plasmarc file needs to be manually changed for a launcher to be in a specific activity or a set of activities
- Testing done with automatic and manual tasks ordering
- Configuration transition works
- Apropriate launchers are loaded for each activity
Diff Detail
- Repository
- R120 Plasma Workspace
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
Here's a few spontaneous thoughts ... not really meant as an in-depth review:
- This is like a step 1, right? It appears the requestAdd/Remove APIs currently add/remove to all activities, so there's no way yet for users to make per-activity launchers?
- 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 AbstractTasksModel::AdditionalRoles::Activities for launcher tasks and rely on TaskFilterProxyModel doing the rest, just like it works for window tasks? The "shownLauncherList" stuff seems to reinvent the wheel at the lower level, when the overall approach in the libtaskmanager codebase is to have a pyramid of dumb list source models that get increasingly filtered/mangled. Or did you try this and it ran into trouble with the ordering ...?
- Note that there shouldn't be any magic that only makes sense in concert with the specific TM applet, the libtaskmanager API should make sense to someone coming at it cold and obey its users. It has users outside of the TM applet.
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.
- Library support for per-activity pinned tasks
- Filtering now checks for the null activity
- Exporting activities list through data member function
- When a launcher is on all activities, the list is now empty
- Relying on the filter model to do the filtering
- Removed debugging output
- Validating the list of activities specified for a launcher
- Nicer handling of duplicate urls