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):

1. 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
2. File Format issues
   • Support for .ini files may need minor adjustments. Currently localized key parts (e.g. en_US.UTF-8@latin in SomeKey[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
3. 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
4. Specification Ambiguities
   • Delineate "most preferred" and "default"
   • Define the format for intent names (domain owner, formalize org.freedesktop.*, or allow x-org.freedesktop.*?)
   • Intents don't have to be D-Bus services, but should follow versioning conventions

added 2 commits

• 6b16b22f - 1 commit from branch xdg:master
• 823c203b - Add intent-apps spec, based on the mime-apps spec.

Compare with previous version

changed the description

mentioned in merge request !45 (closed)

added 1 commit

• 3ed00338 - intentapps-spec: review comments

Compare with previous version

Some URLs of related work

• Draft intents implementation in GLib
• Draft open uri handler in xdg-desktop-portal
• Feature request export thumbnailers in Flatpak
• Draft terminal intent in xdg-specs
• Design default terminal in GNOME Settings

I have to say the name is a bit unfortunate as it sounds awfully simallar to "AppIntents" which is different but somewhat related, in fact the TWIG calls it "app intents" (by mistake?):

App Intents

Andy revived the xdg-spec proposal for app intents

So I was mistakenly thought it was about it. I personally believe it's really important to have in a way that is easy to implement for cross platform apps supporting apple's AppIntents, it's a protocol for sharing app actions with the system, I can definitely see something like that on linux built on top of D-Bus with mechanisms for launching the app and making it available to flatpak (on the implementer side), and there are very compelling use cases for it: voice assistants, system menus (e.g. gnome-shell, krunner), shell scripting, makes shortcuts like apps possible.

I personally believe it's really important to have in a way that is easy to implement for cross platform apps supporting apple's AppIntents, it's a protocol for sharing app actions with the system...

Do you have experience with this API on Apple's platform? I was recently reviewing this, since GLib is intended to be cross-platform, and it would help the bid to get the implementation merged if you could shed some light on the subject. Specifically, how compatible D-Bus vs App Intents might be?

Unfortunately not, I only have experience as a user of shortcuts, I intend to do more research into it and the relevant xdg specs and try to propose a spec, I was surprised to learned they are registered dynamically at runtime that actually makes GLib integration a lot more feasible (things like widgets need to be registered ahead of time in a plist file), although a lot of things in the common framework types seem problematic because GLib doesn't have equivalent types (it's probably fine to leave them unsupported).

I have to say the name is a bit unfortunate as it sounds awfully simallar to "AppIntents" which is different but somewhat related

"Intents" have become pretty much the jargon for this sort of thing; Android uses it as well. I don't think it's a bad thing to adopt the accepted terminology, despite the implementation (and maybe even conceptual meaning) being slightly different.

Better than everyone adopting their own name for the same damn thing, which is why nobody can ever find the motion smoothing setting on their parents' TV to turn it off.

changed the description

We currently also have !45 (closed) open - how are the two MR related, and can the older one be closed? CC: @faure

Hi,

I believe I have implemented the pending "code" suggestions from !45 (closed) in this MR, however it does still has the larger body of important commentary. If it's helpful, I can find some time to update the TODOs and link directly to individual comments.

@mak I have lost interest, so I'm fine with things continuing here. I'll close !45 (closed).

@faure Thank you for the clarification, and sorry that things sometimes take forever to reach any kind of result here (hopefully not for much longer). Maybe this MR is the one that makes it! Thanks for all your work!

added new-specification label