On dimanche 9 mai 2021 07:49:40 CEST Thayne wrote: > On Fri, May 7, 2021 at 2:51 AM Thomas Kluyver <tho...@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, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 _______________________________________________ xdg mailing list xdg@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/xdg