Avoid absolute paths to .desktop files in launcher URLs.
ClosedPublic

Authored by hein on Aug 26 2017, 5:23 PM.

Details

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 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.

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.
hein created this revision.Aug 26 2017, 5:23 PM
Restricted Application added a project: Plasma. · View Herald TranscriptAug 26 2017, 5:23 PM
Restricted Application added a subscriber: plasma-devel. · View Herald Transcript
hein updated this revision to Diff 18820.Aug 26 2017, 5:45 PM

Add comments.

hein updated this revision to Diff 18822.Aug 26 2017, 5:58 PM

One more comment.

broulik accepted this revision.Aug 28 2017, 8:37 AM

Thanks a lot! :)

Verified that D7203 works well with it, even deleted the user-local desktop file at runtime and it immediately picked that up and didn't break \o/

libtaskmanager/tasktools.cpp
44 ↗(On Diff #18822)

Unused

75 ↗(On Diff #18822)

compare with QLatin1String

This revision is now accepted and ready to land.Aug 28 2017, 8:37 AM
This revision was automatically updated to reflect the committed changes.
hein marked 2 inline comments as done.