<div dir="ltr"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 7, 2021 at 2:51 AM Thomas Kluyver <<a href="mailto:thomas@kluyver.me.uk">thomas@kluyver.me.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, 7 May 2021, at 07:14, Thayne McCombs wrote:<br>
<br>
> 2. For terminals that don't natively support DBus (xterm, alacritty, st, <br>
> urxvt, etc.) would you then need a seperate desktop file for a wrapper <br>
> that launched it with dbus (ideally I'd like to see a generic wrapper <br>
> that could work with most/all terminals by passing in options when <br>
> starting it).<br>
<br>
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?<br>
<br>
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.<br></blockquote><div><br></div><div>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. <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> And if the result is just launching a DBus interface, how is this <br>
> different than the existing DBus service mechanism (defining a service <br>
> in <data-dir>/dbus-1/services for  a specific interface)?<br>
<br>
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.<br>
<br></blockquote><div><br></div><div>I suppose it doesn't have a priority system then. But you could set the implementation for the service to your terminal of choice.  <br></div></div></div>