Proposal for an intent-apps spec

[David Faure]

On dimanche 9 mai 2021 07:49:40 CEST Thayne wrote:
> On Fri, May 7, 2021 at 2:51 AM Thomas Kluyver <thomas at kluyver.me.uk> wrote:
> > On Fri, 7 May 2021, at 07:14, Thayne McCombs wrote:
> > > 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? ;-)

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

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