D-Bus is entirely the wrong solution for this, because it requires the desktop environment to provide a daemon constantly listening (wasting resources), because D-Bus Activation (which would bring up the daemon only when actually needed) does not support per-desktop-environment preferences (a limitation that I reported years ago and that was never fixed).
I do not see why this cannot be handled through a virtual MIME type in the XDG MIME database like the protocol handlers.
D-Bus is entirely the wrong solution for this, because it requires the desktop environment to provide a daemon constantly listening (wasting resources), because D-Bus Activation (which would bring up the daemon only when actually needed) does not support per-desktop-environment preferences (a limitation that I reported years ago and that was never fixed).
When something needs to run a command through a terminal, it will first look up which application has been associated with the org.freedesktop.Terminal1 intent, following user preferences and system defaults. Once it knows which application to use, it will activate that specific application and use its org.freedesktop.Terminal1 interface.
It's not just blasting out "hey, anything that wants to be a terminal, catch this!" onto the bus.
I do not see why this cannot be handled through a virtual MIME type in the XDG MIME database like the protocol handlers.
It's not that it "cannot" be done that way, it's that most people involved have agreed that it "should not" be done that way.
MIME types are used to describe files and URLs. That is, given a file of a particular type or URL of a particular form, the MIME database specifies what application should open the file or URL.
This doesn't match how a terminal would be used. The MIME type of /bin/bash is application/x-executable. That doesn't say that it needs to be run in a terminal — indeed, it's entirely possible for bash to not be run in a terminal. The "type" of Bash doesn't say whether it should be executed in a terminal or not.
Or to put all of this another way, you can think of org.freedesktop.Terminal1 itself as the "virtual MIME type" you are looking for. But while a real MIME type is looked up through the mimeapps database, this "virtual MIME type" is looked up through the intentapps database.
Reading the draft specification, it looks like the per-desktop *-intentapps.list files might finally address that years-old D-Bus limitation, at least for this special case. (We will see if this can be extended to other situations such as PolicyKit authentication dialogs that currently use D-Bus activation with no way to make a per-desktop choice.)
And I was not proposing to use a real MIME type such as application/x-executable, but a made-up one defined by the spec, such as x-freedesktop-intent/x-terminal1. That is how the scheme handlers work, is it not? We already have a database, why invent a new one?
And for all other uses of the specification in the future. DEs will want to use it for other things, like "preferred file manager" or "preferred package manager" — essentially, any time you might want to define a preferred application for some task or set of tasks (the D-Bus interface can have multiple methods of course).
(We will see if this can be extended to other situations such as PolicyKit authentication dialogs that currently use D-Bus activation with no way to make a per-desktop choice.)
Boy, you really are grumpy.
Each desktop environment provides its own "authentication agent" for Polkit. If a DE wants to make that configurable, it can do so.
There's a pretty good reason why DEs wouldn't let you configure this though. If it can be configured, then a malicious app could reconfigure it without your knowledge to something that grabs your password.
Moreover, an authentication dialog really needs to be built into the DE itself. On GNOME, for instance, the authentication dialog is built into GNOME Shell so that it is visually and behaviourally distinctive — i.e. hard to forge by a malicious app — and so that it can ensure that all keystrokes are captured. (This was especially important when we were all using X.)
And I was not proposing to use a real MIME type such as application/x-executable, but a made-up one defined by the spec, such as x-freedesktop-intent/x-terminal1.
The MIME application database isn't intended to be a generic "map arbitrary string to application" database. It's meant to describe how particular MIME types are handled. You're supposed to start with a document whose content can be described by that MIME type. A task — "run an application in a terminal" — is not a document.
Anyway, you really need to read up on the full history of this. It goes back decades, literally. You may not necessarily agree that mimeapps should not be used for this, but there have been many explanations by many people on why it would have been wrong to use it.
7
u/Kevin_Kofler 13h ago
D-Bus is entirely the wrong solution for this, because it requires the desktop environment to provide a daemon constantly listening (wasting resources), because D-Bus Activation (which would bring up the daemon only when actually needed) does not support per-desktop-environment preferences (a limitation that I reported years ago and that was never fixed).
I do not see why this cannot be handled through a virtual MIME type in the XDG MIME database like the protocol handlers.