Open Gr3q opened 4 years ago
Unforunately this is hardcoded in glib, which parses the desktop file and launches it. See:
https://gitlab.gnome.org/GNOME/glib/-/blob/master/gio/gdesktopappinfo.c#L2514
This also affects opening terminals via nemo
(when a file's default application is terminal-based). It tries to use gnome-terminal
or xterm
, otherwise, flat out fails (despite the cinnamon terminal being set to something else).
Would an ideal solution be to fix prepend_terminal_to_vector
on gio, or to stop relying on it for handling opening files?
What if you prepend a folder to your path (or /home/<user>/bin
is usually first in the path) and then ln -s /usr/bin/xterm ~/bin/gnome-terminal
. You could even leave gnome-terminal installed with that (the order of precedence is beginning of PATH to the end).
I'm not sure what compromise you could make - at least this solution will be preserved in your home folder. I'd do anything to keep from having to build my own glib/gio. Too bad they couldn't allow an environment variable that it check there before anything else, to pick a default. I don't think they'd add anything to dconf for this, because of how low level the library.
I don't know that you have any choice but to use gio for this, so you have to play along in some way or the other.
Yeah, I've used ln -s $(which alacritty ) ~/.local/bin/xterm
as a workaround. (Note: xterm
uses -e
, like all other terminal emulators; gnome-terminal
uses --
).
Too bad they couldn't allow an environment variable that it check there before anything else, to pick a default. I don't think they'd add anything to dconf for this, because of how low level the library.
I take it that the discussion has been brought up and there was no change of fixing it on the gio
side then? :disappointed:
FWIW, xdg-open (a tool to open any file or URL using the preferred application) uses gio
under gnome, but uses a bunch of different alternatives on other environments. Maybe you could rely on xdg-open
directly? Or check out what is does in non-gio scenario?
There's a lot of factors at play here that I'm not aware of, so feel free to dismiss the suggestion if it's senseless for some reason.
This is still an issue.
Workaround continues to be the same: a wrapper script that just runs exec $TERMINAL $@
.
In GLib 2.76.0, the hardcoded list in prepend_terminal_to_vector
will include xdg-terminal-exec
, which is a proposed spec that allows for a choice in default terminals that is done via .list files. If we add support for it to Cinnamon, then I think it would solve this issue.
In GLib 2.76.0, the hardcoded list in
prepend_terminal_to_vector
will includexdg-terminal-exec
, which is a proposed spec that allows for a choice in default terminals that is done via .list files. If we add support for it to Cinnamon, then I think it would solve this issue.
Did you receive the support from Cinnamon?
I'd rather the spec be reviewed and get some approvals before starting to implement it. I've some reservations about details, and I think it's best to refine it before clients start implementing it.
For example, the preferred terminal is defined in a file with multiple lines. What does each line mean? Why is there more than one? Should they all be tried in order? How is $desktop
defined? Doesn't XDG_SESSION_TYPE
or something else work? POSIX specifies that shell variables should be uppercase, so this is an odd departure. Do the list locations support any drop-in files? Why can't the preference be a symlink instead (e.g.: a symlink to the correct desktop file)?
I think you should present the spec in the freedesktop gitlab and gather some feedback first. I like your intentions here though, it just needs refinement.
The spec isn't very well documented at the moment, so I agree that it definitely needs refinement. I also didn't write the spec, so some decisions are as baffling to me as they are to you. That said, I think I have some answers to some of your questions:
How is
$desktop
defined? Doesn'tXDG_SESSION_TYPE
or something else work? POSIX specifies that shell variables should be uppercase, so this is an odd departure.
$desktop
is not really a shell variable, but a placeholder to substitute the desktop name into the filename of the .list file. According to the sample implementation, it's a lowercase version of whatever is specified in $XDG_CURRENT_DESKTOP
(after splitting it by any :
's). For Cinnamon, $desktop
would be x-cinnamon
, so the full .list filename would be x-cinnamon-xdg-terminals.list
.
I think you should present the spec in the freedesktop gitlab and gather some feedback first.
xdg-terminal-exec
is actually linked in the header comment of the freedesktop gitlab issue for standardising which terminal to run for Run in Terminal desktop entries, but there was no mention of it there since.
I only mention this here since on the GLib side, it was determined by one of its maintainers that it would be a reasonable workaround before a more formal xdg-default-apps
spec was settled on. So I figure Cinnamon could support this too by manipulating the .list files in Preferred Applications to also point to the preferred terminal, if xdg-terminal-exec
exists in the $PATH
.
Considering how other similar implementations work, I'm not sure Cinnamon is going to have to do anything special for this, other than perhaps a change in how we currently set the default terminal in cinnamon settings. Once 2.76 drops somewhere we'll see what's needed.
With xdg-terminal-exec
this bug is resolved. However, the Open in Terminal
button from Nemo still launches some other terminal :(
However, the
Open in Terminal
button from Nemo still launches some other terminal :(
This should be fixed in Nemo 6.2. What version do you have?
I run Nemo 6.0.2, so then this is expected 😄
Issue Application entries flagged to run from Terminal always open in gnome-terminal. Even if it's not installed or a different terminal is set as Default.
In their JS code the Menu Applet (And Cinnamenu) uses this C function to open.
Steps to reproduce
Expected behaviour Terminal opens in the default terminal set in Preferred Applications.
Other information If this is not viable at least indicate with an error that gnome-terminal is needed to be installed.