<table><tr><td style="">hein created this revision.<br />Restricted Application added a project: Plasma.<br />Restricted Application added a subscriber: plasma-devel.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D7561" rel="noreferrer">View Revision</a></tr></table><br /><div><strong>REVISION SUMMARY</strong><div><p>In any place we look up a KService, check if it has a menuId,<br />
and then generate KAStats-style applications: URL with it. Also<br />
learn how to handle applications: URLs.</p>

<p>This was requested by Kai in <a href="https://phabricator.kde.org/D7203" style="background-color: #e7e7e7;
          border-color: #e7e7e7;
          border-radius: 3px;
          padding: 0 4px;
          font-weight: bold;
          color: black;text-decoration: none;" rel="noreferrer">D7203</a>. His patch makes Kate<br />
dynamically add its sessions as jump list actions to a copy of its<br />
.desktop file in $HOME. As the library would generate the absolute<br />
path to a .desktop file e.g. in /usr as launcher URL before, the<br />
TM applet would ignore the overriding copy in $HOME and the actions<br />
wouldn't be found.</p>

<p>This patch won't rewrite existing config, but LauncherTasksModel<br />
will resolve the absolute path to the applications: URL as it goes<br />
through TaskTools, and then return that. The window and startup<br />
tasks models produce those URLs, too, so things match up. Newly-<br />
added launchers will then store the applications: URL in config<br />
directly.</p>

<p>Moving away from storing absolute paths when we can is also nice<br />
in case there is a $HOME .desktop file at the time a launcher is<br />
added which later gets deleted. Using the new storage format, we<br />
will now fall back to a system file instead.</p>

<p>Note the conservative approach taken: We only generate an<br />
applications: URL when the service returns something for menuId().<br />
We don't use KService::storageId() here, which can fall back to<br />
KService::entryPath() - in this case we're better off just using<br />
the absolute path we already have. We still use storageId() when<br />
generating the applications: URL for KAStats db insertions, as<br />
that is more liberal (and matches Kicker).</p>

<p>It makes sense to look at the Kicker backend code to see if should<br />
store applications: URLs (which it already produces to insert into<br />
KAStats) as well.</p>

<p>This will need a subsequent patch to the Task Manager applet to<br />
handle applications: URLs there in code that consumes launcher URLs<br />
to parse things out of .desktop files.</p>

<p>Contains other minor cleanup and fixes, such as porting the<br />
LauncherTasksModel to use TaskTools::runApp (which now understands<br />
preferred: URLs as well), a fix for a small logic error there (the<br />
&& before the !isApplication should have been ||, now moot), and<br />
not needlessly opening and parsing a .desktop file in<br />
TaskTools::appDataFromUrl.</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R120 Plasma Workspace</div></div></div><br /><div><strong>BRANCH</strong><div><div>master</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D7561" rel="noreferrer">https://phabricator.kde.org/D7561</a></div></div><br /><div><strong>AFFECTED FILES</strong><div><div>libtaskmanager/launchertasksmodel.cpp<br />
libtaskmanager/startuptasksmodel.cpp<br />
libtaskmanager/tasktools.cpp<br />
libtaskmanager/xwindowtasksmodel.cpp</div></div></div><br /><div><strong>To: </strong>hein<br /><strong>Cc: </strong>plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart, lukas<br /></div>