GNOME Bugzilla – Bug 627943
'Run in terminal' should use the preferred terminal
Last modified: 2018-05-24 12:43:53 UTC
I have konsole as my preferred terminal, but when I choose to run any other preferred application in terminal, GNOME Terminal is being used. The preferred terminal should be used instead.
Just to make it clearer, here is how to reproduce it: 1. Install konsole. 2. Go to 'Preferred Applications' and select it as the Terminal Emulator. 3. Go to the 'Internet' tab and choose 'Custom' for the Web Browser 4. Write 'lynx %s' and choose 'Run in terminal. 5. Try to open a link in the Preferred Web Browser to find that it runs in GNOME Terminal instead of konsole. Bug 628662 may be related.
It's caused by prepend_terminal_to_vector() in glib/gio/gdesktopappinfo.c Should probably start using GSettings to get the preferred terminal when the control-center is ported.
I can confirm I'm seeing the same thing although in my case I want to use urxvt. For me this is failing when using the "SSH" plugin in Synapse. According to: http://live.gnome.org/GnomeGoals/GSettingsMigration glib is marked as not needing porting to GSettings. Does this mean a patch to fix this would be rejected as bringing in another dependency on the low lever Glib?
Ignore the previous silly question, I see GSettings is actually part of glib/gio!
Created attachment 191446 [details] [review] Provisional patch to fix the problem This is a first cut at fixing the problem. If anyone can review that would be great.
Review of attachment 191446 [details] [review]: ::: gio/gdesktopappinfo.c @@ +1,1 @@ +/* -*- mode: C; c-file-style: "gnu"; indent-tabs-mode: nil; -*- */ Don't add that. @@ +969,3 @@ term_argv = g_new0 (char *, 3); + if (term_settings) It can never be NULL, as g_settings_new() cannot fail (it will abort if the schema is not present). @@ +975,3 @@ + { + term_argv[0] = check; + term_argv[1] = g_settings_get_string(term_settings, "exec_arg"); Spaces before brackets. @@ +2098,2 @@ info->terminal = (flags & G_APP_INFO_CREATE_NEEDS_TERMINAL) != 0; + info->term_settings = g_settings_new(TERMINAL_PREFERENCES_SCHEMA); You're leaking ->term_settings.
Created attachment 191456 [details] [review] Working patch, fixed a small typo I've now tested with synapse and the SSH plugin. The connection is now done under my preferred terminal.
Our posting crossed, I shall make those changes. I wasn't sure what the lifetime of GAppInfo was, so yes it will leak currently. When does it get freed?
Review of attachment 191456 [details] [review]: ::: gio/gdesktopappinfo.c @@ +937,3 @@ static gboolean +prepend_terminal_to_vector (GSettings *term_settings, + int *argc, please, align the arguments @@ +969,3 @@ term_argv = g_new0 (char *, 3); + if (term_settings) as Bastien said, this cannot be NULL you also need to add: g_object_unref (info->term_settings); @@ +2098,2 @@ info->terminal = (flags & G_APP_INFO_CREATE_NEEDS_TERMINAL) != 0; + info->term_settings = g_settings_new(TERMINAL_PREFERENCES_SCHEMA); please, add a space between the function name and the (.
Created attachment 191483 [details] [review] Final version of the patch Updates following review comments. * Only uses schema if it exists * g_object_unref GSettings data on object destruction * formatting fixes for consistent style
Review of attachment 191483 [details] [review]: > Written-by: Alex Bennée <alex@bennee.com > Signed-Off-By: Alex Bennée <alex@bennee.com> Remove those, there's already authorship, and we don't use SOB lines. > To set up an alternative terminal you need to set the right gconf keys: It's not gconf. > Version 3, following code review. Remove that, the information is already in bugzilla. ::: gio/gdesktopappinfo.c @@ +257,3 @@ + and it's not a dependency of glib we have to check at runtime + */ + char const * const *schemas = g_settings_list_schemas (); Declare and assign separately. @@ +262,3 @@ + while (*cur) + { + char const * const *schemas = g_settings_list_schemas (); ...) == 0) spaces.
Created attachment 191753 [details] [review] Updated patch Updated following latest review.
While waiting for review could we at least move this bug on from UNCONFIRMED to NEW? Or does the confirmation need to be done by one of the bug squad?
Review of attachment 191753 [details] [review]: FWIW, we don't use bugzilla statuses for anything. ::: gio/gdesktopappinfo.c @@ +260,3 @@ + schemas = g_settings_list_schemas (); + local->term_settings = NULL; + while ( *schemas ) Use a for loop instead. @@ +262,3 @@ + while ( *schemas ) + { + char const * const *schemas; Please follow the existing coding style. @@ +263,3 @@ + { + if ( g_strcmp0 (TERMINAL_PREFERENCES_SCHEMA, *schemas) == 0 ) + schemas = g_settings_list_schemas (); You need to break out of the loop once you've found it, otherwise you're looping for nothing.
*** Bug 663894 has been marked as a duplicate of this bug. ***
The consensus here was that glib should ship its own schema to handle the preferred terminal and use it, instead of relying on gsettings-desktop-schemas, which is GNOME specific.
That makes sense. However in the meantime I've given up on Gnome-Do and moved to Gnome 3 which makes it easy to open my specific terminal. As a result this patch is purely of academic interest to me now. I suggest someone more familiar with the coding style of glib take it forward if this functionality is desired by the maintainers.
*** Bug 703498 has been marked as a duplicate of this bug. ***
+ /* Note that gnome-terminal takes -x and + * as -e in gnome-terminal is broken we use that. */ + term_argv[1] = g_strdup ("-x"); BTW, -x has been deprecated in g-t for a long time. The only supported way to pass arguments is using '-- ' to terminate the g-t options and append the arguments.
*** Bug 743626 has been marked as a duplicate of this bug. ***
The worst part of this bug is that if you choose another terminal with the "update-alternatives" method, then the result is inconsistent. Sometime you will have your terminal emulator, sometime (for example using the nautilus-open-terminal extension, which I personally use a lot) you get gnome-terminal. I know I can link the gnome-terminal binary to x-terminal-emulator. But it does not seem really a nice thing to do, and there is still the strangeness of the "-x/-e" options lying around.
(The nautilus issue doesn't belong in this bug. If you use nautilus-open-terminal, it would be an issue with that extension. If however, as I think is quite likely, you actually use the nautilus extension that superseded nautilus-open-terminal and that exists now in gnome-terminal's git repo, this is NOTABUG since that extension quite deliberately directly calls gnome-terminal.)
...sorry --- I am not an expert here. What I see is that nautilus-open-terminal 0.20 is doing the following: - detect if the window is local or not - if local, set a variable to a concoction which is basically $SHELL, otherwise it tries to dig a suitable ssh/sftp command; - and then calls app = g_app_info_create_from_commandline (command_line, NULL, G_APP_INFO_CREATE_NEEDS_TERMINAL, &error); and then executes the app. I supposed that this call would wrap the terminal chosen by the part of the code in this bug report --- but I repeat, I am very probably wrong.
Created attachment 297897 [details] [review] Add schema as a property This patch introduces a "schema" property that can be used to set a schema to be used to locate the preferred terminal definition. It is heavily derived from Alex's patch. It has the following advantages over the previous patch: - Does not rely on Gnome. - No need of a glib owned schema. - No change of default behaviour. - Easy use for any desktop environment. - Up to date with today's code base. I first tried to implement schema as a virtual class member which seems more elegant, but subclassing GDesktopAppInfo is a pain in the ass because constructing methods call static ones. Thus I implemented it as an object property.
Review of attachment 297897 [details] [review]: Which would mean that every single "user" of GDesktopAppInfo would need to set this value. This is not backwards-compatible, and a lot of work when we could just as easily use a schema shipped with glib.
Is there a way with a glib-owned schema to have a non-fixed (i.e.: desktop dependent) location for preferred terminal? In any case, the patch at #25 can easily be adapted to set its own schema by default rather than no schema at all.
I'm not a developer, but simply check for the existence of x-terminal-emulator and calling it *before* the other options will solve it in 99% of the cases...
Would you accept a relocatable glib-owned schema with a schemapath property and a hardcoded default value for it ?
(In reply to Romano Giannetti from comment #27) > I'm not a developer, but simply check for the existence of > x-terminal-emulator and calling it *before* the other options will solve it > in 99% of the cases... x-terminal-emulator is a Debian (and thus Ubuntu) specific wrapper, so it would not solve the issue.
Created attachment 298013 [details] [review] Implement preferred terminal with a glib-owned schema - The schema is relocatable and applied to the gnome2 path by default for backward compatibility. - Property "terminal-path" can be set to override this default path.
A few comments: - using gsettings is not acceptable here unless it is done as part of a wider and better-thought-out system for selecting default handlers - we could abuse the mime system here in the same way as we do for url handlers - we could also use 'implements=' - I don't think adding x-terminal-emulator as a first thing to check is going to harm anybody (although I think Debian's alternatives system is pretty fundamentally broken -- that's up to Debian to resolve) - but: why can't Debian just patch in x-terminal-emulator for themselves in order to save the extra stat() for all of the other distros that will never have this installed? In short, I think that this is a WONTFIX, but I recommend that Debian start to carry a patch.
Well, I too do not like so much the alternative system... but even without that, there should be a way to choose your terminal. In my case, I'd like to fire up terminator; and once upon a time it worked (you used gsettings set org.gnome.desktop.default-applications.terminal exec /usr/bin/terminator ) ...but now I do not really know how to do it. I have nothing against gnome-terminal, really, but it's just a matter of desktop consistency (and yes, I can just link gnome-terminal to whatever; not elegant, I think).
(In reply to Ryan Lortie (desrt) from comment #31) > A few comments: > > - using gsettings is not acceptable here unless it is done as part of a > wider > and better-thought-out system for selecting default handlers The terminal isn't a mime-type handler, or a URI scheme handler. At least x-scheme-handler/foo has some legitimacy.
(In reply to Bastien Nocera from comment #33) > (In reply to Ryan Lortie (desrt) from comment #31) > > A few comments: > > > > - using gsettings is not acceptable here unless it is done as part of a > > wider > > and better-thought-out system for selecting default handlers > > The terminal isn't a mime-type handler, or a URI scheme handler. At least > x-scheme-handler/foo has some legitimacy. I didn't mean to imply that we would think up some fake mimetype or uri scheme in order to identify terminals -- just that there is enough overlap here that a similar system might be useful for all three.
*** Bug 592857 has been marked as a duplicate of this bug. ***
To be frank, downstream users are getting tired of this, and it doesn't reflect well on the GNOME project. From their perspective: 1) You're making excuses. 2) You're oblivious to uses of glib outside of the complete GNOME Desktop. 3) Your dev team is brain-damaged for simply hardcoding a terminal search routine instead of doing the right thing the first time out. I'm sure if any of them were to relay their opinions to you (which they have generally said they won't, because they feel it to be an exercise in futility), they might phrase it more charitably, but they have spoken quite bluntly on their home turf: https://github.com/mate-desktop/mate-panel/issues/57 >Knowing how the Gnome guys are oblivious to anything outside of Gnome, >I think it's no use to ask them to fix this issue in GLib, that's why >I made a patch handling mate-terminal and posted it in the Debian BTS https://bugzilla.redhat.com/show_bug.cgi?id=1096011#c4 >Ok, I understand the problem, we use glib to launch desktop files, >and glib has this hackish function http://crunchbang.org/forums/viewtopic.php?pid=385082#p385082 >Then your hopes are to write a patch that works universally, >and send it to the GNOME developers. Good luck with either >(no sarcasm intended) http://forums.mate-desktop.org/viewtopic.php?f=2&t=3327#p10258 >It is a glib "feature" https://github.com/mate-desktop/mate-desktop/issues/121 >IMHO, glib will never be patched for mate :-( >The fix has to be done in mate and, as said before, is not easy. https://forum.xfce.org/viewtopic.php?id=6112 >You can't, they hard-coded defaults in the code. >I've suggested a work around but probably nobody cares. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773915#32 >You're welcome to try, but frankly, I seriously doubt that upstream >could be convinced to include even those two lines of code (let alone a >test for each known xterm-compatible terminal or wrapper, for distros >not using an alternative system) just to accommodate the (many) users of >non-GNOME desktops which rely on Glib to launch applications in a terminal. -------------------------------------------------- I could go on and on here, but I think I've made my point. Adding "HIG" keyword because it potentially violates "Require as little work from the user as possible" and "Anticipate errors" from the Design Principles.
I would like to second this message 100%. This is dreadful. It drives users away from applications that rely on glib. Users like me. I follow this bug for five years now, but I have long given up using the application that led me here. I now use a Qt alternative instead. Comments from the developers like "why doesn't Debian patch this?" are just laughable. There are many possible solutions, some of which where proposed here. Another one would be to follow, if exists, the "TERMINAL" environment variable. It is used by a few window managers. Look at those silly arguments. "… save the extra stat() for all of the other distros" Really? Who started doing heuristic stat()s on a few terminal binaries they personally know in the first place? Give me a break. This is RIDICULOUS and it goes on for years now. Guess what, every user could place a symlink called "x-terminal-emulator" in their PATH on their own to solve this issue, Debian or not. They could set an environment variable to solve this issue, or set a gconfig variable on their own to solve this issue. But currently, they can *not* solve this issue without being root on the system, or if they are, breaking their installation. And with currently, I mean for at least the last five years. Because that single stat() would cost them sooo much! Why can't the Debian developers patch this?!
Please, read comment #31. Then read it again, before making uninformed comments.
Calling other comments uninformed is not helpful to the discussion. In fact my comment is heavily referring to #31.
(In reply to Johannes Jordan from comment #39) > Calling other comments uninformed is not helpful to the discussion. Then you simply decided to ignore it. > In fact my comment is heavily referring to #31. Comment #31, which is from the GLib maintainer, specified that the approach of attachment #298013 [details] is not going to work as: > - using gsettings is not acceptable here unless it is done as part of > a wider and better-thought-out system for selecting default handlers There's an outline for a different approach: > - we could abuse the mime system here in the same way as we do for url > handlers > > - we could also use 'implements=' Then there's a different section on x-terminal-emulator, which is a Debian-only approach: > - I don't think adding x-terminal-emulator as a first thing to check is > going to harm anybody *but*, since it's a Debian-only thing, Debian should also carry a patch to add it, since it does not make sense on any other software distribution. To recap: * if we want to have an option to specify a different terminal emulator on top of the existing "check every known terminal emulator if gnome-terminal is not installed", then we need to find a better way to store it and define it than GSettings * if you are using Debian, and if you're using the alternatives system that Debian uses, then you should ask Debian to ship a distro patch that makes GLib aware of x-terminal-emulator, and checks it before checking for gnome-terminal These two issues are completely orthogonal.
Thank you for addressing my comment. What I wanted to express is that the arguments used here against solving the problem are not correctly tackling the issue. Allison Ryan Lortie talks about a few possible solutions, which is good, and concludes with a WONTFIX, which is bad. He recommends that of all glib users, only Debian users should find a solution to the problem, by the hands of the Debian developers. However this is a problem of glib, not Debian, and it applies to anybody, not only Debian users. After five years of this bug lingering around, I would expect a willingness towards a pragmatic solution to the problem. The notion that supporting "x-terminal-emulator" can only work for Debian is plain short-sighted and here is why. As I tried to communicate, the maintainers of the software cited in comment #36 could advise their users to set-up an x-terminal-emulator themselves. Something that many users might be very happy to do, even if they use Arch Linux, FreeBSD or whatnot. It is something you can do as an unpriviledged user easily and using a custom PATH is a very old and understood concept in POSIX systems. I also noted that other pragmatic solutions, like an environmental variable that a user sets, do exist. It is a solution that I would prefer. Or you could even say, "Why not both?". The arguments used here however, come down to "better have no solution than any solution that doesn't outright solve it for everybody". And I don't believe this is how the issue should be tackled after such a long time, how many more years do you want to wait for this magical solution to pop up?
I fail to understand why "using gsettings" must necessarily create a dependency. GLib could be configured to use it if it is available, and fall back to other methods when it is not. I've also noticed that a number of terminal emulators set $COLORTERM to the name of their binary upon installation. Some systems also use $TERMINAL for a similar purpose, as noted in comment #37. I think that the very least that could be done would be to check these two variables first and see if either of them provide a valid console. Even if a user's system does not ordinarily set them, it could be documented that a user can manually set one of them in order to evoke the desired behavior
Relying on environment variables is troublesome. They're not always set correctly. Further, they're difficult to change. Comment 31 outlines what a proper fix would be. Something aligned across desktops (fits in with an existing or new freedesktop.org standard) would be best. Then you'll notice that people will spend whatever effort is needed. Suggest to advise the maintainers of the various software to propose a patch which follows the idea from comment 31.
(In reply to Olav Vitters from comment #43) > Relying on environment variables is troublesome. They're not always set > correctly. Further, they're difficult to change. Comment 31 outlines what a > proper fix would be. Something aligned across desktops (fits in with an > existing or new freedesktop.org standard) would be best. Then you'll notice > that people will spend whatever effort is needed. > > Suggest to advise the maintainers of the various software to propose a patch > which follows the idea from comment 31. If you can check x-terminal-emulator, then why not at least try $COLORTERM? Two extra stat calls and a getenv shouldn't be the end of the world. It's a simple, if imperfect solution that could be applied at least until somebody has a better idea. I mean, this bug is starting to feel like the nirvana fallacy at work.
> Relying on environment variables is troublesome. They're not always set > correctly. Further, they're difficult to change. How difficult is it really? LXDE/LXQT: http://linuxscoop.com/wp-content/uploads/2015/03/Manjaro-0.8.12-LXQt-LXQt-Session-Settings.jpg KDE/Plasma: http://unix.stackexchange.com/questions/6551/how-can-i-set-env-variables-so-that-kde-recognizes-them Ubuntu/Unity: http://askubuntu.com/questions/82120/how-do-i-set-an-environment-variable-in-a-unity-session
(In reply to ipatrol6010 from comment #44) > If you can check x-terminal-emulator, then why not at least try $COLORTERM? The contents of the COLORTERM envvar are not suitable to distinguish terminals, and certainly not to be taken as the name of a programme executable.
Let me chime in --- again, I am not a developer but just a humble user with sometime writes some (local use) program. What I used to do to solve this problem was to move gnome-terminal away and substitute it with a softlink to my preferred term application or a wrapper script. Not elegant, but effective, and it works. Sort of. But I think that hardcoding *any* terminal as default is if not broken, at least ill-advised. What happens if tomorrow we have a better standard version of terminal in gnome with a different name? Or the option to choose a voice-enabled terminal? Like "gnome-superterm" of "gnome-voiceterm"? Shouldn't we be able to use old programs without recompiling? I am not sure which method is the best --- env variable, gschema, dconf, even a dot file in home directory... but I really think that a configurability here will not only be handy now, but a future-proof addition. Just my two cents, and back to simlinking.
(In reply to Christian Persch from comment #46) > (In reply to ipatrol6010 from comment #44) > > If you can check x-terminal-emulator, then why not at least try $COLORTERM? > > The contents of the COLORTERM envvar are not suitable to distinguish > terminals, and certainly not to be taken as the name of a programme > executable. Yes, some terminals simply set it to "1", and others set it to something generic like "xterm-color", but I think it should at least be tested to see if in fact it refers to an actual binary in the system's path, and move on if it doesn't. (In reply to Romano Giannetti from comment #47) Yeah. I'm not a C programmer (Python here), but even I could see that hardcoding the names of some common terminal emulators into the source code is not exactly good coding practice. Now, it would be wonderful if POSIX, LSB, or freedesktop had some standardized way of indicating the user's preferred terminal, but as of now there isn't one. If you're not willing to use gsettings for this, for whatever reason, then the traditional way of indicating such preferences on *nix systems is either an environment variable, or a configuration file somewhere. I can' simply symlink xterm away because I use software that has a real dependency on that program. Why they do is probably just as ill-advised as here (or even more so!), but that's not something I can fix, nor should I have to. In the mean time, having xterm be the default terminal for calling these programs from launchers is a severe detriment to my workflow, as I can't even do simple things like copy-paste. This is really becoming a bug up my ***, no pun intended.
(In reply to ipatrol6010 from comment #48) > > I can' simply symlink xterm away [...] > well, the first terminal searched for is gnome-terminal... so if you symlink it it will be used before xterm, leaving xterm alone...
(In reply to Romano Giannetti from comment #49) Thanks for the suggestion. Still doesn't fix the *actual problem* though. I'm a single-user desktop setup, so I can make symlinks wherever and to whatever I want, but not everyone is and can.
Comment 31 outlines what is wanted. This is being ignored continuously and all kinds of other suggestions are proposed with the argument "until something better comes along". But that's exactly what was said already: comment 31 This is going in circles.
(In reply to Olav Vitters from comment #51) > Comment 31 outlines what is wanted. This is being ignored continuously and > all kinds of other suggestions are proposed with the argument "until > something better comes along". But that's exactly what was said already: > comment 31 In that comment, Allison proposed to close this bug as a WONTFIX and pawn the problem off on the downstream users, a "resolution" I, to be perfectly honest, find absurd. Each of the other commenters on this bug have suggested various, quite reasonable solutions to this problem. They have taken time out of their day to come here and do so. The path of least resistance would have been to simply make up the patches downstream and not tell the GNOME project a thing. But that goes against every principle of the free software community and, while this in particular is not a security issue, is exactly the sort of mentality that lead to the Debian-OpenSSL fiasco. If the developers are intimating that, "We won't support any uses of glib outside of the complete GNOME Desktop, and therefore won't fix any bugs that don't exist within it," then I strongly suggest they just upfront come out and say that, so us downstream projects can look into finding or building a replacement. I would note however, that would essentially make glib and gnome-desktop dependencies of *each other*. > This is going in circles. Believe me, I've noticed.
(In reply to ipatrol6010 from comment #52) > If the developers are intimating that, "We won't support any uses of glib > outside of the complete GNOME Desktop, and therefore won't fix any bugs that > don't exist within it," then I strongly suggest they just upfront come out Ok, I guess it is time to be very clear: Continued effort to insinuate bad effort of GNOME developers will not be tolerated. Suggestions we haven't tried various times to explain what would be a good solution will be considered as bad faith as well. If you want to complain about what I've just said: bugmaster@gnome.org. Do NOT complain in this bugreport. You've acknowledged we've explained enough times what has been asked, yet continue to suggest bad faith. Enough is enough. Anything other than constructive comments will be removed/hidden. That means pretty much any comment other than a patch. Upfront and clear communication!
I found a solution. No patch needed. If you have a sane environment, with your $HOME/bin prepending your /usr/bin path, you can just ln -s /usr/bin/terminator $HOME/bin/gnome-terminal and be done. No root needed. (adapt for your preferred term). It would be nice to have the fist check for, for example, "glib-terminal-emulator" so that you can still have gnome-terminal available; but I understand that this is not really a high-impact or important bug, and there are more important thing to do. Iĺl add a patch in that sense for consideration. Thanks to all the developers for their work on GNOME.
Created attachment 321568 [details] [review] Check for a glib-terminal-emulator first From the patch: + /* check for glib-terminal-emulator. It normally doens't exist, but + that way an user can personalize the called terminal by + ln -s /path/to/your/terminal $HOME/bin/ + and having $HOME/bin prepending the standard $PATH */
I don't want to wade into a holy war, but if anyone has tips getting a workaround to work, I'd appreciate it. I am using Ubuntu 16.10 + Unity. When I uninstall and symlink /usr/bin/gnome-terminal (in its location or in $HOME/bin, makes no difference) to terminator, the "Open in terminal" action has no effect at all. Only reinstalling restores the functionality. Syslog shows the following error: nautilus-autostart.desktop[3591]: Error creating terminal: The name org.gnome.Terminal was not provided by any .service files Some googling suggests that gnome-terminal is now using a client/server architecture. Is there still a workaround to change the terminal opened with the right-click menu in Nautilus?
(In reply to Erik Moeller from comment #59) > I don't want to wade into a holy war, but if anyone has tips getting a > workaround to work, I'd appreciate it. > > I am using Ubuntu 16.10 + Unity. When I uninstall and symlink > /usr/bin/gnome-terminal (in its location or in $HOME/bin, makes no > difference) to terminator, the "Open in terminal" action has no effect at > all. Only reinstalling restores the functionality. > > Syslog shows the following error: > > nautilus-autostart.desktop[3591]: Error creating terminal: The name > org.gnome.Terminal was not provided by any .service files > > Some googling suggests that gnome-terminal is now using a client/server > architecture. Is there still a workaround to change the terminal opened with > the right-click menu in Nautilus? I can't exactly tell you how to fix this, but the reason is that nautilus is not started by command line but by dbus activation. The file needed for that should reside in /usr/share/dbus-1/services/org.gnome.Terminal.service (Fedora 25). In my case this file just contains these lines: [D-BUS Service] Name=org.gnome.Terminal SystemdService=gnome-terminal-server.service Exec=/usr/libexec/gnome-terminal-server
Users can add their own context menu entries with FileManager-Actions (formerly nautilus-actions). It'd be good if Nautilus at least offered an option to hide its built-in "Open in Terminal" action, which cannot be changed to use other terminal emulator than Gnome Terminal. With the FileManager-Actions, I can add my own "Open in Terminal" action, but I don't need 2.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME'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.gnome.org/GNOME/glib/issues/338.