Skip to content
  • Eike Hein's avatar
    Avoid absolute paths to .desktop files in launcher URLs. · a47d1f19
    Eike Hein authored
    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.
    
    Subscribers: plasma-devel
    
    Tags: #plasma
    
    Differential Revision: https://phabricator.kde.org/D7561
    a47d1f19