hein created this revision. Restricted Application added a project: Plasma. Restricted Application added a subscriber: plasma-devel.
REVISION SUMMARY In any place we look up a KService, check if it has a menuId, and then generate KAStats-style applications: URL with it. Also learn how to handle applications: URLs. This was requested by Kai in https://phabricator.kde.org/D7203. His patch makes Kate dynamically add its sessions as jump list actions to a copy of its .desktop file in $HOME. As the library would generate the absolute path to a .desktop file e.g. in /usr as launcher URL before, the TM applet would ignore the overriding copy in $HOME and the actions wouldn't be found. This patch won't rewrite existing config, but LauncherTasksModel will resolve the absolute path to the applications: URL as it goes through TaskTools, and then return that. The window and startup tasks models produce those URLs, too, so things match up. Newly- added launchers will then store the applications: URL in config directly. Moving away from storing absolute paths when we can is also nice in case there is a $HOME .desktop file at the time a launcher is added which later gets deleted. Using the new storage format, we will now fall back to a system file instead. Note the conservative approach taken: We only generate an applications: URL when the service returns something for menuId(). We don't use KService::storageId() here, which can fall back to KService::entryPath() - in this case we're better off just using the absolute path we already have. We still use storageId() when generating the applications: URL for KAStats db insertions, as that is more liberal (and matches Kicker). It makes sense to look at the Kicker backend code to see if should store applications: URLs (which it already produces to insert into KAStats) as well. This will need a subsequent patch to the Task Manager applet to handle applications: URLs there in code that consumes launcher URLs to parse things out of .desktop files. Contains other minor cleanup and fixes, such as porting the LauncherTasksModel to use TaskTools::runApp (which now understands preferred: URLs as well), a fix for a small logic error there (the && before the !isApplication should have been ||, now moot), and not needlessly opening and parsing a .desktop file in TaskTools::appDataFromUrl. REPOSITORY R120 Plasma Workspace BRANCH master REVISION DETAIL https://phabricator.kde.org/D7561 AFFECTED FILES libtaskmanager/launchertasksmodel.cpp libtaskmanager/startuptasksmodel.cpp libtaskmanager/tasktools.cpp libtaskmanager/xwindowtasksmodel.cpp To: hein Cc: plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart, lukas
