Proposal for an intent-apps spec

[David Faure]

Hello everyone,

I just created
https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_requests/45
with the proposal for an intent-apps spec, modeled after the mime-apps spec
(but without the concept of adding/removing associations).

For context:

* The desktop entry spec mentions Implement=<intent name> already for some
time, but AFAIK this isn't used anywhere yet?

* What's missing is a way to let the user (or the sysadmin or the distro)
decide which alternative to prefer (possibly depending on the desktop
environment). mimeapps does this nicely for mimetypes, so intentapps just
reuses that solution, but outside the world of mimetypes

* This came up in https://gitlab.freedesktop.org/xdg/xdg-specs/-/issues/54
where we're discussing "Have a standard way for users to specify which
terminal should open .desktop applications with Terminal=true".
The solution involves implementing a DBus interface (dubbed
org.freedesktop.Terminal1). This is similar to the existing
org.freedesktop.FileManager1 DBus interface. All applications implementing
org.freedesktop.Terminal1 will specify
Implements=org.freedesktop.Terminal1 in their desktop file, and intent-
apps.lst files can then be used to pick the preferred one.

I am willing to implement this on the KDE side, I'm especially interested in
feedback from whoever feels like implementing this in glib and other
implementations.

[Bastien Nocera]

Post by David Faure
Hello everyone,
I just created
https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_requests/45
with the proposal for an intent-apps spec, modeled after the mime-
apps spec
(but without the concept of adding/removing associations).
* The desktop entry spec mentions Implement=<intent name> already for some
time, but AFAIK this isn't used anywhere yet?
* What's missing is a way to let the user (or the sysadmin or the distro)
decide which alternative to prefer (possibly depending on the desktop
environment). mimeapps does this nicely for mimetypes, so intentapps just
reuses that solution, but outside the world of mimetypes
* This came up in
https://gitlab.freedesktop.org/xdg/xdg-specs/-/issues/54
where we're discussing "Have a standard way for users to specify which
terminal should open .desktop applications with Terminal=true".
The solution involves implementing a DBus interface (dubbed
org.freedesktop.Terminal1). This is similar to the existing
org.freedesktop.FileManager1 DBus interface. All applications
implementing
org.freedesktop.Terminal1 will specify
Implements=org.freedesktop.Terminal1 in their desktop file, and intent-
apps.lst files can then be used to pick the preferred one.

This still doesn't fix the problem of knowing _how_ to launch
applications in those terminals when the options are different, and
expect different values, which was the problem in the first place.

Listing the .desktop files which correspond to terminal emulators
wasn't really the hard part of the problem...

Please also make a formatted version of the spec available, it's easier
to read than docbook diffs ;)

Post by David Faure
I am willing to implement this on the KDE side, I'm especially
interested in
feedback from whoever feels like implementing this in glib and other
implementations.

[David Faure]

Post by Bastien Nocera

Post by David Faure
Hello everyone,
I just created
https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_requests/45
with the proposal for an intent-apps spec, modeled after the mime-
apps spec
(but without the concept of adding/removing associations).
* The desktop entry spec mentions Implement=<intent name> already for some
time, but AFAIK this isn't used anywhere yet?
* What's missing is a way to let the user (or the sysadmin or the distro)
decide which alternative to prefer (possibly depending on the desktop
environment). mimeapps does this nicely for mimetypes, so intentapps just
reuses that solution, but outside the world of mimetypes
* This came up in
https://gitlab.freedesktop.org/xdg/xdg-specs/-/issues/54
where we're discussing "Have a standard way for users to specify which
terminal should open .desktop applications with Terminal=true".
The solution involves implementing a DBus interface (dubbed
org.freedesktop.Terminal1). This is similar to the existing
org.freedesktop.FileManager1 DBus interface. All applications implementing
org.freedesktop.Terminal1 will specify
Implements=org.freedesktop.Terminal1 in their desktop file, and intent-
apps.lst files can then be used to pick the preferred one.

This still doesn't fix the problem of knowing _how_ to launch
applications in those terminals when the options are different, and
expect different values, which was the problem in the first place.

This is handled by the DBus interface.

It's not
* lookup desktop file from intent
* execute the Exec line of that desktop file, which will be like xterm -e..

It's
* lookup desktop file from intent
* start that process
* make a DBus call to it

Post by Bastien Nocera
Please also make a formatted version of the spec available, it's easier
to read than docbook diffs ;)

I'm having trouble doing that. There's no discount-mkd2html executable on
binary, I found a mkd2html and added a symlink with that name, but I'm not
sure that's right. Now ./update.py (with Local=True and a line in specs.idx
pointing to HEAD) runs to the end but doesn't generate any HTML for the
spec...

[Thayne McCombs]

Post by David Faure

Post by Bastien Nocera
This still doesn't fix the problem of knowing _how_ to launch
applications in those terminals when the options are different, and
expect different values, which was the problem in the first place.

This is handled by the DBus interface.
It's not
* lookup desktop file from intent
* execute the Exec line of that desktop file, which will be like xterm -e..
It's
* lookup desktop file from intent
* start that process
* make a DBus call to it

1. Where is the DBus interface for launching the terminal defined? It
isn't in this spec, is it part of a different spec?

2. For terminals that don't natively support DBus (xterm, alacritty, st,
urxvt, etc.) would you then need a seperate desktop file for a wrapper
that launched it with dbus (ideally I'd like to see a generic wrapper
that could work with most/all terminals by passing in options when
starting it).


And if the result is just launching a DBus interface, how is this
different than the existing DBus service mechanism (defining a service
in <data-dir>/dbus-1/services for  a specific interface)?

[Thomas Kluyver]

Post by Thayne McCombs
1. Where is the DBus interface for launching the terminal defined? It
isn't in this spec, is it part of a different spec?

I think KDE & Gnome developers are planning to make a spec for that, but there isn't one yet. There's a lot of discussion about it on the issue you created here:

https://gitlab.freedesktop.org/xdg/xdg-specs/-/issues/54

Post by Thayne McCombs
2. For terminals that don't natively support DBus (xterm, alacritty, st,
urxvt, etc.) would you then need a seperate desktop file for a wrapper
that launched it with dbus (ideally I'd like to see a generic wrapper
that could work with most/all terminals by passing in options when
starting it).

I assume you would need wrappers, yes. You could write one wrapper for many terminal emulators, but if you have more than one installed, you recreate the same problem: how does the wrapper decide which one you want?

The neater solution with the proposed intent-apps spec would be for each terminal emulator to have its own D-Bus wrapper, so you can use intent-apps to choose between them. If it gets traction, I imagine that distros would ship these wrappers in their packages for different terminal emulators.

Post by Thayne McCombs
And if the result is just launching a DBus interface, how is this
different than the existing DBus service mechanism (defining a service
in <data-dir>/dbus-1/services for  a specific interface)?

A service file points to one specific program which provides an interface. The Implements= key allows several applications to provide the same interface - saying 'this is *a* terminal' rather than 'this is *the* terminal' - and the proposed intent-apps spec is for picking a preferred one.

Thomas

[Thayne]

Post by Thomas Kluyver

Post by Thayne McCombs
2. For terminals that don't natively support DBus (xterm, alacritty, st,
urxvt, etc.) would you then need a seperate desktop file for a wrapper
that launched it with dbus (ideally I'd like to see a generic wrapper
that could work with most/all terminals by passing in options when
starting it).

I assume you would need wrappers, yes. You could write one wrapper for
many terminal emulators, but if you have more than one installed, you
recreate the same problem: how does the wrapper decide which one you want?
The neater solution with the proposed intent-apps spec would be for each
terminal emulator to have its own D-Bus wrapper, so you can use intent-apps
to choose between them. If it gets traction, I imagine that distros would
ship these wrappers in their packages for different terminal emulators.

You would need seperate desktop files for sure, but I think it would be
possible, and reasonable to have a single D-Bus wrapper executable that is
flexible enough to be used for most terminals, just called with different
arguments. So for example the desktop file for alacritty would use
something like `xdg-dbus-terminal-launcher alacritty --command-option=-e
--working-dir-option=--working-directory --keep-open-option=--hold`. Note
that the working directory and environment can be set by the wrapper before
forking.

Post by Thomas Kluyver

Post by Thayne McCombs
And if the result is just launching a DBus interface, how is this
different than the existing DBus service mechanism (defining a service
in <data-dir>/dbus-1/services for a specific interface)?

A service file points to one specific program which provides an interface.
The Implements= key allows several applications to provide the same
interface - saying 'this is *a* terminal' rather than 'this is *the*
terminal' - and the proposed intent-apps spec is for picking a preferred
one.

I suppose it doesn't have a priority system then. But you could set the
implementation for the service to your terminal of choice.

[David Faure]

Post by Thayne

Post by Thomas Kluyver

Post by Thayne McCombs
2. For terminals that don't natively support DBus (xterm, alacritty, st,
urxvt, etc.) would you then need a seperate desktop file for a wrapper
that launched it with dbus (ideally I'd like to see a generic wrapper
that could work with most/all terminals by passing in options when
starting it).

I assume you would need wrappers, yes. You could write one wrapper for
many terminal emulators, but if you have more than one installed, you
recreate the same problem: how does the wrapper decide which one you want?
The neater solution with the proposed intent-apps spec would be for each
terminal emulator to have its own D-Bus wrapper, so you can use intent-apps
to choose between them. If it gets traction, I imagine that distros would
ship these wrappers in their packages for different terminal emulators.

You would need seperate desktop files for sure, but I think it would be
possible, and reasonable to have a single D-Bus wrapper executable that is
flexible enough to be used for most terminals, just called with different
arguments. So for example the desktop file for alacritty would use
something like `xdg-dbus-terminal-launcher alacritty --command-option=-e
--working-dir-option=--working-directory --keep-open-option=--hold`. Note
that the working directory and environment can be set by the wrapper before
forking.

This is a great idea. Do I hear a volunteer for implementing this with as few
dependencies as possible? ;-)

Post by Thayne

Post by Thomas Kluyver

Post by Thayne McCombs
And if the result is just launching a DBus interface, how is this
different than the existing DBus service mechanism (defining a service
in <data-dir>/dbus-1/services for a specific interface)?

A service file points to one specific program which provides an interface.
The Implements= key allows several applications to provide the same
interface - saying 'this is *a* terminal' rather than 'this is *the*
terminal' - and the proposed intent-apps spec is for picking a preferred
one.

I suppose it doesn't have a priority system then. But you could set the
implementation for the service to your terminal of choice.

Right. And as I wrote in the spec, implementation-specific defaults are
possible too (so that gnome defaults to gnome-terminal and kde defaults to
konsole, for instance, until the user says otherwise).

[Thayne McCombs]

Post by David Faure

Post by Thayne

Post by Thomas Kluyver

Post by Thayne McCombs
2. For terminals that don't natively support DBus (xterm, alacritty, st,
urxvt, etc.) would you then need a seperate desktop file for a wrapper
that launched it with dbus (ideally I'd like to see a generic wrapper
that could work with most/all terminals by passing in options when
starting it).

I assume you would need wrappers, yes. You could write one wrapper for
many terminal emulators, but if you have more than one installed, you
recreate the same problem: how does the wrapper decide which one you want?
The neater solution with the proposed intent-apps spec would be for each
terminal emulator to have its own D-Bus wrapper, so you can use intent-apps
to choose between them. If it gets traction, I imagine that distros would
ship these wrappers in their packages for different terminal emulators.

You would need seperate desktop files for sure, but I think it would be
possible, and reasonable to have a single D-Bus wrapper executable that is
flexible enough to be used for most terminals, just called with different
arguments. So for example the desktop file for alacritty would use
something like `xdg-dbus-terminal-launcher alacritty --command-option=-e
--working-dir-option=--working-directory --keep-open-option=--hold`. Note
that the working directory and environment can be set by the wrapper before
forking.

This is a great idea. Do I hear a volunteer for implementing this with as few
dependencies as possible? ;-)

Sure, I can do that.

[Bastien Nocera]

Post by David Faure

Post by Bastien Nocera

Post by David Faure
Hello everyone,
I just created
https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_requests/45
with the proposal for an intent-apps spec, modeled after the mime-
apps spec
(but without the concept of adding/removing associations).
* The desktop entry spec mentions Implement=<intent name> already
for
some
time, but AFAIK this isn't used anywhere yet?
* What's missing is a way to let the user (or the sysadmin or the distro)
decide which alternative to prefer (possibly depending on the desktop
environment). mimeapps does this nicely for mimetypes, so
intentapps
just
reuses that solution, but outside the world of mimetypes
* This came up in
https://gitlab.freedesktop.org/xdg/xdg-specs/-/issues/54
where we're discussing "Have a standard way for users to specify which
terminal should open .desktop applications with Terminal=true".
The solution involves implementing a DBus interface (dubbed
org.freedesktop.Terminal1). This is similar to the existing
org.freedesktop.FileManager1 DBus interface. All applications implementing
org.freedesktop.Terminal1 will specify
Implements=org.freedesktop.Terminal1 in their desktop file, and intent-
apps.lst files can then be used to pick the preferred one.

This still doesn't fix the problem of knowing _how_ to launch
applications in those terminals when the options are different, and
expect different values, which was the problem in the first place.

This is handled by the DBus interface.
It's not
* lookup desktop file from intent
* execute the Exec line of that desktop file, which will be like xterm -e..
It's
* lookup desktop file from intent
* start that process
* make a DBus call to it

How do you plan on implementing that in, say, xterm, or rxvt?

Note that specs are usually only accepted when implementations already
exist for a vendor-ed version of it, or a WIP version of it.

Post by David Faure

Post by Bastien Nocera
Please also make a formatted version of the spec available, it's easier
to read than docbook diffs ;)

I'm having trouble doing that. There's no discount-mkd2html
executable on
binary, I found a mkd2html

This is the software:
https://github.com/Orc/discount

But this is only used for the index page, not for the specs themselves.

Post by David Faure
and added a symlink with that name, but I'm not
sure that's right. Now ./update.py (with Local=True and a line in specs.idx
pointing to HEAD)

You need to make it point to your branch. But you could also generate a
single page just for your document.

Post by David Faure
runs to the end but doesn't generate any HTML for the
spec...

[David Faure]

Post by Bastien Nocera

Post by David Faure
* lookup desktop file from intent
* start that process
* make a DBus call to it

How do you plan on implementing that in, say, xterm, or rxvt?

It doesn't have to be part of xterm itself.
All we need is a helper executable that implements the DBus interface and
launches xterm (and another one for rxvt).

In fact my implementation for konsole isn't part of the konsole executable but
is in a separate helper process, because starting konsole opens a terminal
window already (and adding a --daemon flag like in dolphin seems complicated
for other reasons).

The main issue with the xterm is where the helper for it should live.
I am thinking of writing one in KDE so users can select it, but then other DEs
would have to do the same if they want one too, to avoid depending on the KDE
helper... not great.
OTOH from what I understand, only KDE wants to make this configurable, in
gnome/glib xterm would just be the fallback if gnome-terminal isn't installed?
Maybe I misunderstand, though.

Post by Bastien Nocera
Note that specs are usually only accepted when implementations already
exist for a vendor-ed version of it, or a WIP version of it.

I'm implementing a WiP version of it already, taking into account the feedback
in https://gitlab.freedesktop.org/xdg/xdg-specs/-/issues/54, but I need the
DBus API to be finalized before I can upstream it, it'll be hard to change
afterwards (for source and binary compatibility reasons).
I have the DBus part working, my next step is to implement the intent-apps
part.

Ideally, someone would start implementing all this in glib in parallel,
to avoid spec change requests coming after the spec is finalized...

Post by Bastien Nocera
You need to make it point to your branch. But you could also generate a
single page just for your document.

Yep I ended up doing that.
http://www.davidfaure.fr/2021/intent-apps-spec-1.0.html

[David Faure]

Post by Bastien Nocera
Please also make a formatted version of the spec available, it's easier
to read than docbook diffs ;)

Done:
http://www.davidfaure.fr/2021/intent-apps-spec-1.0.html

[Thomas Kluyver]

There was a discussion recently about how a default application for a mime-type was chosen when no mimeapps.lst specified a preference - some launchers were giving semi-random results that changed unexpectedly.

As you said, the new spec closely follows mime-apps. I think it would be a good idea to head off similar issues in the future by giving a bit more detail in the recommendation for what to do when no preference is found. This is the relevant bullet point at present:

"if after all files are handled, we have not yet found a default application, select the most-preferred application (according to associations) that supports the intent"

But what makes an application most-preferred, apart from this spec? AFAIK, there is no other way to decide this in general. Of course, a launcher may have a hardcoded default for specific interfaces it recognises - e.g. KDE might pick Konsole for org.freedesktop.Terminal1 - but it should be prepared to handle interfaces it doesn't know.

I can see two possible recommendations that make sense:

- Pick the default in a simple, consistent manner (e.g. first desktop file sorted by name), and make it obvious how the user should set their preference if they don't like it.
- Pick an arbitrary default, and then write it as the preference in XDG_CONFIG_HOME, so the same application will be used until the user picks another one (or uninstalls that one).

It might also be worth saying that the spec doesn't rule out using Implements= for cases where there's no default application - where you're interested in all the applications implementing an interface, rather than just one. I don't think anything in the new spec is a problem for that, but it might be good to make that explicit.

Other than that, I think it looks like a nice addition. :-)

Thomas

Post by David Faure
Hello everyone,
I just created
https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_requests/45
with the proposal for an intent-apps spec, modeled after the mime-apps spec
(but without the concept of adding/removing associations).
* The desktop entry spec mentions Implement=<intent name> already for some
time, but AFAIK this isn't used anywhere yet?
* What's missing is a way to let the user (or the sysadmin or the distro)
decide which alternative to prefer (possibly depending on the desktop
environment). mimeapps does this nicely for mimetypes, so intentapps just
reuses that solution, but outside the world of mimetypes
* This came up in https://gitlab.freedesktop.org/xdg/xdg-specs/-/issues/54
where we're discussing "Have a standard way for users to specify which
terminal should open .desktop applications with Terminal=true".
The solution involves implementing a DBus interface (dubbed
org.freedesktop.Terminal1). This is similar to the existing
org.freedesktop.FileManager1 DBus interface. All applications implementing
org.freedesktop.Terminal1 will specify
Implements=org.freedesktop.Terminal1 in their desktop file, and intent-
apps.lst files can then be used to pick the preferred one.
I am willing to implement this on the KDE side, I'm especially interested in
feedback from whoever feels like implementing this in glib and other
implementations.
--
Working on KDE Frameworks 5
_______________________________________________
xdg mailing list
https://lists.freedesktop.org/mailman/listinfo/xdg

[David Faure]

Post by Thomas Kluyver
There was a discussion recently about how a default application for a
mime-type was chosen when no mimeapps.lst specified a preference - some
launchers were giving semi-random results that changed unexpectedly.
As you said, the new spec closely follows mime-apps. I think it would be a
good idea to head off similar issues in the future by giving a bit more
detail in the recommendation for what to do when no preference is found.
"if after all files are handled, we have not yet found a default
application, select the most-preferred application (according to
associations) that supports the intent"
But what makes an application most-preferred, apart from this spec? AFAIK,
there is no other way to decide this in general.

You're right, this sentence (taken from mime-apps-spec) doesn't make sense.

Post by Thomas Kluyver
Of course, a launcher may
have a hardcoded default for specific interfaces it recognises - e.g. KDE
might pick Konsole for org.freedesktop.Terminal1 - but it should be
prepared to handle interfaces it doesn't know.

Not sure what you mean. The only (DBus) interface that we expect to use for
this is org.freedesktop.Terminal1. Maybe you meant "implementation" rather
than "interface"? In that case I agree, see below.

Post by Thomas Kluyver
- Pick the default in a simple, consistent manner (e.g. first desktop file
sorted by name), and make it obvious how the user should set their
preference if they don't like it.
- Pick an arbitrary default, and then
write it as the preference in XDG_CONFIG_HOME, so the same application will
be used until the user picks another one (or uninstalls that one).

Or Eli's suggestion of a GUI to ask the user.

In my opinion, all three possibilities make sense, but should only be
recommendations for an implementation specific behaviour. We don't need to
actually specify this part.
E.g. I can understand if the gnome implementation doesn't go for "sort by
name" since that would select konsole over gnome-terminal for every new user
;)
So it seems much more likely that the implementation specific fallback would
be something like "use the implementation from the same desktop environment /
software stack, if available, and only then, fallback to sorting by name, or
picking and saving, or asking the user."

Post by Thomas Kluyver
It might also be worth saying that the spec doesn't rule out using
Implements= for cases where there's no default application - where you're
interested in all the applications implementing an interface, rather than
just one. I don't think anything in the new spec is a problem for that, but
it might be good to make that explicit.

Sure, that's exactly what I intend to do in the KDE GUI configuration module
to let the user choose which terminal to use.

I have updated
https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_requests/45
based on your feedback above.

Post by Thomas Kluyver
Other than that, I think it looks like a nice addition. :-)

Thanks!

[Thomas Kluyver]

Hi David,

Post by David Faure

Post by Thomas Kluyver
Of course, a launcher may
have a hardcoded default for specific interfaces it recognises - e.g. KDE
might pick Konsole for org.freedesktop.Terminal1 - but it should be
prepared to handle interfaces it doesn't know.

Not sure what you mean. The only (DBus) interface that we expect to use for
this is org.freedesktop.Terminal1. Maybe you meant "implementation" rather
than "interface"? In that case I agree, see below.

I did mean 'interface' :-) . I was just trying to say that the launcher (/desktop) wouldn't have a hardcoded default for every interface it has to handle. That's probably self-evident, and your edit resolves this concern.

Post by David Faure

Post by Thomas Kluyver
- Pick the default in a simple, consistent manner (e.g. first desktop file
sorted by name), and make it obvious how the user should set their
preference if they don't like it.
- Pick an arbitrary default, and then
write it as the preference in XDG_CONFIG_HOME, so the same application will
be used until the user picks another one (or uninstalls that one).

Or Eli's suggestion of a GUI to ask the user.
In my opinion, all three possibilities make sense, but should only be
recommendations for an implementation specific behaviour. We don't need to
actually specify this part.

Yup, I agree - this is a recommendation rather than a specification. I like what you've written for this now. Given the confusion with the equivalent case in mime-apps, I might add a sentence like:

"However, whatever we do should give a consistent result, e.g. it should not depend on the order of an unsorted list of files from a directory."

I'm not sure about the last sentence you've now added:

"A similar algorithm, apart from stopping at the first success, can be used to list all available implementations of the intent."

I don't think it can, because, there's no reason to think that a given implementation is listed in any intentapps.list file. As things stand, to find all implementations, you would have to scan all desktop files. It would be possible to build a cache like mimeinfo.cache, but that's a separate concern from selecting the preferred application.

Best wishes,
Thomas

[David Faure]

Post by Thomas Kluyver
Yup, I agree - this is a recommendation rather than a specification. I like
what you've written for this now. Given the confusion with the equivalent
"However, whatever we do should give a consistent result, e.g. it should not
depend on the order of an unsorted list of files from a directory."

OK, I added "In any case it should be consistent across runs rather than
random (e.g. based on the order of an unsorted list of files from a
directory)".

Post by Thomas Kluyver
"A similar algorithm, apart from stopping at the first success, can be used
to list all available implementations of the intent."
I don't think it can, because, there's no reason to think that a given
implementation is listed in any intentapps.list file.

Right. I should say:

"Similarly, those intentapps.list files, parsed in the same order, can also be
used to sort all available implementations by preference."

How does that sound?

Post by Thomas Kluyver
As things stand, to find all implementations, you would have to scan all
desktop files.

Correct.

Post by Thomas Kluyver
It would be possible to build a cache like mimeinfo.cache, but that's a
separate concern from selecting the preferred application.

And that can be implementation-specific (in KDE we already have such a cache,
called ksycoca, and IIRC mimeinfo.cache is glib-specific). There are benefits
to sharing caches, but let's not make that a requirement at this point :-)

[Thomas Kluyver]

Post by David Faure
OK, I added "In any case it should be consistent across runs rather than
random (e.g. based on the order of an unsorted list of files from a
directory)".

Sounds good, thanks!

Post by David Faure

Post by Thomas Kluyver
"A similar algorithm, apart from stopping at the first success, can be used
to list all available implementations of the intent."
I don't think it can, because, there's no reason to think that a given
implementation is listed in any intentapps.list file.

"Similarly, those intentapps.list files, parsed in the same order, can also be
used to sort all available implementations by preference."
How does that sound?

Better, but I think it still implies that reading all intentapps.list files is sufficient to find all implementations of a given intent. I would say something like:

"It's also possible to put several implementations of an intent in order of preference by reading all intentapps.list files in the order above. But these files cannot be used to find all implementations of an intent; the desktop files are the canonical source of that information."

Post by David Faure

Post by Thomas Kluyver
It would be possible to build a cache like mimeinfo.cache, but that's a
separate concern from selecting the preferred application.

And that can be implementation-specific (in KDE we already have such a cache,
called ksycoca, and IIRC mimeinfo.cache is glib-specific). There are benefits
to sharing caches, but let's not make that a requirement at this point :-)

I think mimeinfo.cache is meant to be shared - it's created by a standalone update-desktop-database command which is maintained under xdg (desktop-file-utils repo). But I agree that there's no need to detail caching in the spec at this point.

Best wishes,
Thomas

[David Faure]

Post by Thomas Kluyver
Better, but I think it still implies that reading all intentapps.list files
is sufficient to find all implementations of a given intent. I would say
"It's also possible to put several implementations of an intent in order of
preference by reading all intentapps.list files in the order above. But
these files cannot be used to find all implementations of an intent; the
desktop files are the canonical source of that information."

OK, I'll use that, I'll just replace "But" with "Remember however that", since
IMHO "But" sounds a bit too much like there's a flaw in the spec, while this
is perfectly normal and expected.

https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_requests/45 updated.

Post by Thomas Kluyver

Post by David Faure

Post by Thomas Kluyver
It would be possible to build a cache like mimeinfo.cache, but that's a
separate concern from selecting the preferred application.

And that can be implementation-specific (in KDE we already have such a
cache, called ksycoca, and IIRC mimeinfo.cache is glib-specific). There
are benefits to sharing caches, but let's not make that a requirement at
this point :-)

I think mimeinfo.cache is meant to be shared - it's created by a standalone
update-desktop-database command which is maintained under xdg
(desktop-file-utils repo).

It's not however part of a spec (AFAIK), and KDE has a pre-existing binary
cache.

[Thomas Kluyver]

Post by David Faure
OK, I'll use that, I'll just replace "But" with "Remember however that", since
IMHO "But" sounds a bit too much like there's a flaw in the spec, while this
is perfectly normal and expected.

That makes sense, thanks!

Thomas