D7561: Avoid absolute paths to .desktop files in launcher URLs.

Eike Hein noreply at phabricator.kde.org
Sat Aug 26 17:23:45 UTC 2017


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20170826/b8ab8901/attachment-0001.html>


More information about the Plasma-devel mailing list