More about "intents": Several improvements to desktop files and caches

[Jerome Leclanche]

I recently brought up "intents" on this list and several people didn't
know what they actually were, and I didn't want to talk about them too
much until I had a clear idea of it all.

To be clear: This is about more than just intents, and some of what
I'm going to be talking about can be taken care of separately. This is
about a set of backwards-compatible improvements to desktop files that
will allow for much improved integration and interoperation of various
apps.


Problem #1
Apps cannot enumerate other apps of a specific type. A couple of
common use cases:
    - A system settings app wants to know about every window manager,
terminal emulator, ... so it can show them in a dropdown to the user.
    - An email client wants to open a contact manager.
    - A volume control wants to open a volume mixer.

There is groundwork to solve this problem with Categories. What's
missing is a category cache, and more categories.
GNOME uses X-GNOME-Provides for windowmanager and panel. This is
something that could be solved with these changes, imo.
PCMan wrote a patch to desktop-file-utils to generate a [Category
Cache] in mimeinfo.cache. I will talk later in this email about the
mimeinfo.cache file.
https://github.com/PCMan/desktop-file-utils/commit/9d543f9090b96854606e70bc1f43b1bc98132c9e


Problem #2
Apps cannot set a default app of a specific category. Eg "default
terminal emulator", "default window manager". This is an evolution of
problem #1, as those same system settings apps would want to actually
set the default app.
defaults.list (or was it mimeapps.list now?) can be reused for this.
So we can do eg:
[Default Applications Category]
TerminalEmulator=qterminal.desktop

Now, none of this takes into account having a different default for
two different desktop environments (eg. konsole on kde and qterminal
on lxqt). I don't know whether that's a good thing or not. As a
desktop environment, I would *like* to integrate with whatever was set
as default in a previously-used DE. I also don't really think xdg
specs should be dictating actual differences between DEs, the whole
point is common functionality. If there is to be DE-specific behaviour
to be implemented, it probably should be implemented at the DE level.
I'd also like to think with improved app integration, users are not
going to *want* different defaults in different DEs but simply run
whatever is installed. Hey, I can dream, right?


Problem #3
XDG makes no conceptual difference between "View" and "Edit".
Currently, the only defined action is "open".
Common use cases:
 - I want to *view* an HTML file in a web browser. I want to *edit* an
HTML file in a text editor.
 - I want to *view* an image in an image viewer (like feh). I want to
*edit* an image in the GIMP.
 - I don't want to *edit* a PDF in the GIMP, even though it can *open* it.
 - I really don't like the GIMP.

There was talk about generic intents for View and Edit but this just
makes things a lot more confusing than it should. I think the best
solution is a set of two new keys: "View" and "Edit" (or MimeTypeView
and MimeTypeEdit, doesn't matter the name). These two keys will be
like the MimeType key except the given mime types will be associated
with a more specific action of viewing or editing a file.
The MimeType key will then be the more generic "Open" action, which
will still be the default unless the app chooses otherwise. For
example, xdg-open can gain an --edit or --view flag. A File Manager
will probably want to use the action "View" by default (and this could
be configured further).

Implementation proposal: In the mimeinfo.cache, we will need two new
sections. "MIME View Cache" and "MIME Edit Cache". In defaults.list,
we will also need "Default View Applications" and "Default Edit
Applications" sections, for symmetry.
TBD: The "Open" order. Obviously if there are no Open actions
available but an Edit or a View action is present, we'll want to
fallback on either. Do we fall back to Edit or View by default?


Problem #4
Desktop Actions cannot be bound to MIME types.
Use case: An application offers different "modes" (with different
command lines) for different file types.
I have encountered this use case with mplayer2 (aka mplayer aka mpv).
The app behaves differently on audio and video files, as audio files
offer no interface other than console; it is then problematic when
opening a file from a file manager (either you get a terminal for
video files or you get audio files that cannot be stopped).
I brought this up in the past: Desktop Actions cannot have a MimeType
key. This is partly
because it was never requested before, partly because it requires new
syntax in mimeinfo.cache.
Worth noting: This can all partly be solved with different desktop
files but I HATE that. To me, the concept of "one desktop file per
app" is strongly engrained. It is much more declarative and on top of
that it allows treating two actions differently in, for example, a
launcher/runner/menu rather than show up app duplicates.

Implementation proposal: In mimeinfo.cache, we identify desktop files
by special, currently-reserved syntax. For example:
image/png=foo.desktop;bar.desktop[Gallery];. ALTERNATIVELY,
image/png=foo.desktop;bar.desktop[Desktop Action Gallery]; The latter
is more verbose but more extensible.
This *should* be backwards-compatible as most implementations will
probably just think it's a missing desktop file. Needs testing.


Finally: Intents
Intents is a name I originally picked before I even knew "android
intents" were a thing (I've been thinking about them for a long, long
time...). Learning about android intents was very instructive and they
inspired a lot of the current functionality of intents.

The idea: An app invokes another app's functionality through dbus. The
functionality offered by the app is standardized and the user is
presented with the choice of app to use for said functionality.

Example: A contact/user manager lets you modify a user's avatar by
either *picking a file through the file manager* or *using a "Camera"
app to take a picture*.
(For more example, just open an android phone and look at the way
various actions can be executed through different files)

So instead of integrating with a specific app, the developer
integrates with the intent and all apps implementing the intent are
then supported.

The actual intent is a dbus interface of the same name as the intent
itself. For example, xdg.intents.Camera (and the method here would be
eg. xdg.intents.Camera.TakePicture). The name does not matter at the
moment as long as the interface is the same.

There's a lot TBD still. For example: Do we require apps implementing
an intent to support every method of the intent? I don't think it's
necessary due to dbus introspection letting us figure out whether a
method is supported.
This would, once again, require adding more categories in
mimeinfo.cache and defaults.list (or mimeapps.list, I really have no
idea which is the deprecated one). And those would be unrelated to
mimetypes really.
-> So now we're at the point where these two files have a lot of
sections and it's worth mentioning the name of the file itself has
lost its meaning. In an ideal world I would say "Move to a generic
desktop.cache and associations.list name", but this all needs to be
backwards compatible and I strongly believe it's better to have it all
in one file. I am fine with deprecating the current file names in
favour of a new, generic one but.. yeah.

Further point about intents: Something called "Portals" was brought up
in the last desktop summit. I tried to get an update about this with
no response from anyone. Portals are the concept of communication
between two sandboxed apps, once again in the same style as android.
This would work just fine with intents and would be handled by the
newly-implemented kdbus (kernel dbus). I suppose different interfaces
might have to be supported depending on whether you want a filename
(dbus, fast, doesn't work sandboxed) or the full file data (kdbus
only, slow on dbus, only way to get it working sandboxed).


Bonus problem: Binding applications to a url glob. For example,
github.com/* opens in the github desktop app. Android intents do that
and that's the only reason I'm bringint this up; this is imho nearly
irrelevant to the desktop. I have to admit I'd like to see it and it
would be pretty easy to do, but the only real use case would be mobile
OSes supporting xdg.


Phew. Please, please bring up anything that doesn't make sense or
seems silly and explain why; there's a lot to think about in all this
and working on it can (and does) give me tunnel vision. I also don't
deal that much with dbus, so please correct me if I'm making wrong
assumptions.
If you are coming to FOSDEM, I will be demoing much of this in the
Desktops devroom so come say hi and shout at me.
J. Leclanche