| dfaure | |
| davidedmundson |
| Frameworks |
This offers convenience API for launching a specific KServiceAction on a KService.
Plasma has a few places (Task Manager, Kickoff, KRunner) where we deal with service actions. Right now they all pretty much call KRun::runCommand(action.exec()).
This new API ensures it gets the same capabilities (including URL expansion) and proper startup info (app icon bouncy cursor) as regular service launches.
Depends on D28278
| Automatic diff as part of commit; lint not applicable. |
| Automatic diff as part of commit; unit tests not applicable. |
Excellent idea!
I'm glad to see that the class design allows these kinds of things.
| src/gui/applicationlauncherjob.cpp | ||
|---|---|---|
| 57 | Maybe this should even be a Q_ASSERT? We can't do much with a null service here. | |
Interestingly, D28268 is also about executing a KServiceAction, but I cannot port it to this API, because the KService::Ptr is not known in that (public) method.
The caller, KFileItemActions, knows it so it could pass it to a new overload with one more parameter, but this seems to point out that maybe a KServiceAction is enough? KDesktopFileActions uses the name and icon from the action rather than the namd and icon from the service. Dunno if that's better though?
KDesktopFileActions uses the name and icon from the action rather than the namd and icon from the service. Dunno if that's better though?
I think we want to communicate to the user that "[Firefox icon] Firefox" is starting, not "[No icon] New incognito tab", which is why we use the service icon and name.
Makes sense.
But in many places, having to provide both is problematic. E.g. when the KServiceAction is the value<>() of a QAction.
I'll look into storing the KService::Ptr inside the KServiceAction. If this works out, we can remove the KService::Ptr argument from this class...