Created attachment 118945 [details] Ad hoc patch to launch terminal xdg-open does not spawn terminals for desktop files with `Terminal=true`. For example consider the following configuration: `~/.local/share/applications/ranger.desktop`: [Desktop Entry] Name=ranger Type=Application Terminal=true Exec=ranger %F `~/.local/share/applications/mimeapps.list`: [Default Applications] inode/directory=ranger.desktop inode/mount-point=ranger.desktop Then I expect ranger to be opened in a terminal upon running: xdg-open / What currently happens is: (a) if running the command from a non-terminal context, xdg-open tries to execute ranger without terminal. This errors and xdg-open falls back to execute mimeopen which ignores mimeapps.list and only looks at defaults.list and therefore confusingly may use another default. (b) if running the command within a terminal, ranger is opened in the current terminal. While this is fine, I think it would be fine as well to spawn a new terminal. This applies to xdg-utils 1.1.1. The attached patch spawns a new terminal asynchronously indiscriminately of case (a) versus case (b). It uses the TERMINAL environment variable, similar to what `mimeopen` does.
We should probably start installing xdg-terminal then and use it from xdg-open when Terminal=true.
I'd like to encourage use of (and possibly semi-mandatory dependency) gvfs-open/kde-open(5)... rather than use (and depend on) previously unsupported/unreleased tools (like xdg-terminal). I guess these options don't need to be mutually exclusive either.
> We should probably start installing xdg-terminal then and use it from xdg-open when Terminal=true. I didn't know about xdg-terminal. Using a dedicated tool like this makes probably more sense than the ad-hoc hack I included above. However, I noticed two main drawbacks in the `terminal_generic` implementation that currently render the tool useless in the absence of a desktop-environment (which is the only case where the tool would be invoked by xdg-open): 1. the $TERM variable does not necessarily correspond to a binary on the system - Using urxvt, the variable is set to 'rxvt-unicode-256color' - Using terminator, the variable is set to 'xterm' by default, but I usually change it to 'xterm-256color', because that worked better in some circumstances (don't remember what exactly) 2. there is no way to use arbitrary terminals. E.g. terminator uses `-x` instead of `-e` > I'd like to encourage use of [...] gvfs-open/kde-open(5)... xdg-open already uses these commands in the presence of a desktop environment. Do you suggest to use and require either of these tools even for systems without desktop environment?
(In reply to Thomas Gläßle from comment #3) > 1. the $TERM variable does not necessarily correspond to a binary on the > system > > - Using urxvt, the variable is set to 'rxvt-unicode-256color' > - Using terminator, the variable is set to 'xterm' by default, but I > usually change it to 'xterm-256color', because that worked better in > some circumstances (don't remember what exactly) I don't know why it uses $TERM. It's totally wrong IMHO. > 2. there is no way to use arbitrary terminals. E.g. terminator uses `-x` > instead of `-e` > > > > I'd like to encourage use of [...] gvfs-open/kde-open(5)... > > xdg-open already uses these commands in the presence of a desktop > environment. Do you suggest to use and require either of these tools even > for systems without desktop environment? I suggest we invent a variable $TERMINAL that will work similarly to $BROWSER and $MAILER.
> Do you suggest to use and require either of these tools even for systems without desktop environment? Yes, that is what I am suggesting. No DE => means no "environment", so not exactly something very supportable to begin with.
(In reply to Rex Dieter from comment #5) > > Do you suggest to use and require either of these tools even for systems without desktop environment? > > Yes, that is what I am suggesting. > > No DE => means no "environment", so not exactly something very supportable > to begin with. I disagree. There are many people who use a window manager without a full-blown desktop environment and we have already come a long way to support them. I'm not sure it was such a good idea to implement everything in shell but here we are.
(In reply to Rex Dieter from comment #2) > I'd like to encourage use of (and possibly semi-mandatory dependency) > gvfs-open/kde-open(5)... rather than use (and depend on) previously > unsupported/unreleased tools (like xdg-terminal). > > I guess these options don't need to be mutually exclusive either. I suppose that if we don't want to add another API/tool, we could just put the terminal code in xdg-open's generic mode and be done with it. But xdg-terminal seems like a useful tool to me.
I think we need to define terms then. to *me*, a window manager counts as an environment, so is supportable. However, I would argue that any environment without a minimal gtk (gvfs-open) or qt/kde (kde-open5) runtime... would be harder to support. Hence, my recommendation to consider having at least one of those as strongly-recommended dependencies. As I also conceded in my initial comment, this is not mutually exclusive to using xdg-terminal either (though that is less optimal and a slippery slope).
> I suggest we invent a variable $TERMINAL that will work similarly to $BROWSER and $MAILER. mimeopen already uses $TERMINAL in the manner that TERMINAL="terminator -x" would be a valid setting, while TERMINAL=terminator:urxvt:xterm is not. Since mimeopen is not completely independent (it is actually used by xdg-open as fallback), I don't really like the different usage of the same variable in both tools. I'd suggest using $TERMINAL as in mimeopen (as in the patch above), or using a $TERMCMD or similar in the way that $BROWSER is used. (ranger currently uses $TERMCMD in a way that would be upwoard compatible to the suggested use). > No DE => means no "environment", so not exactly something very supportable to begin with. It is supportable with minimal necessary user configuration (setting $TERMCMD, or $TERMINAL or whatever)
Alternative thought: Allow to define a .desktop file for terminal applications, i.e. something like: [Desktop Entry] name=terminator GenericName=X Terminal Emulator Exec=terminator -x %F MimeType=x-terminal-emulator where xdg-open or similar tools can find suitable terminals via the mimetype. In a way, I find this rather elegant, since it could use an existing very extensible mechanism., e.g. users could then easily define their preferred terminal in the mimeapps.list file using the existing mechanism. On the other hand though, I'm not sure whether this makes sense since the concept of mimetypes doesn't really match command execution.
This proposal is extending and arguably changing existing xdg spec and best practice, not something I'm willing to accept without further discussion and consensus first. I'd suggest starting that discussion onlist, http://lists.freedesktop.org/mailman/listinfo/xdg (Fwiw, I do like the idea behind this)
Hello, I came here to open a bug for this exact reason, but I found this old bug that is still relevant. For what a newcomer's opinion is worth, I find Thomas' $TERMINAL a nice idea: sane default, easily customizable and does not require changes to the XDG specification. However I see it has not been merged, so maybe something else's been going on. Has there been any progress on this? P.S. this is my first comment here, so if I did something wrong I apologize. Please point me in the right direction. Thank you.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xdg/xdg-utils/issues/84.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.