Proposal for an intent-apps spec

[David Faure]

On lundi 3 mai 2021 12:04:30 CEST Bastien Nocera wrote:
> On Mon, 2021-05-03 at 11:44 +0200, David Faure wrote:
> > 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.
> 
> 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

> 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...

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5