Draft: Add intent-apps spec, based on the mime-apps spec.
HTML output at http://andyholmes.ca/public/intent-apps/intent-apps-spec.html
Overview of Tasks (as of last edit):
- Platform Issues
- Currently, e.g.
org.freedesktop.FileManager1
is started by calling an interface method, which should happen in platform libraries like GLib/KDE. -
David Faure commented: Dolphin isn't DBus-activatable as org.kde.dolphin because it's not a "unique application", it registers as org.kde.dolphin-$PID. The first launched Dolphin registers under the additional name org.freedesktop.FileManager1, so DBus-activating org.freedesktop.FileManager1 does work, but not the above strategy.
- Comment thread 1/2
- Comment thread 2/2
- Currently, e.g.
- File Format issues
- Support for
.ini
files may need minor adjustments. Currently localized key parts (e.g.en_US.UTF-8@latin
inSomeKey[en_US.UTF-8@latin]=value
) only allow characters from lang codes. We would require the characters for mime-types (/
,+
), probably added to the Desktop Entry spec format description - This may be problematic if a Flatpak'd
.desktop
file is exported to a host that doesn't support the new format
- Support for
- D-Bus Policy vs. Mechanism
- Option 1: a portal can provide the names and resolution can happen portal-side (best current choice?)
- Option 2:
intent-apps.list
can be bind-mounted into sandboxes - Option 3: Containers1 interface
- Specification Ambiguities
- Delineate "most preferred" and "default"
- Define the format for intent names (domain owner, formalize
org.freedesktop.*
, or allowx-org.freedesktop.*
?) - Intents don't have to be D-Bus services, but should follow versioning conventions
Edited by Andy Holmes