GNOME Bugzilla – Bug 600035
Request: Allow opening a terminal, cross-desktop compatible
Last modified: 2011-11-12 16:16:04 UTC
It is ironic that GIO allows to open any command or application in a controlling terminal, supposedly in a cross-desktop way, but it doesn't allow to open a terminal itself. --- (How to open a command in terminal:) import gio vim = gio.AppInfo("vim", flags=gio.APP_INFO_CREATE_NEEDS_TERMINAL) vim.launch() --- Since these the latter feature must be able to share much of the implementation of the former already existing feature, it should be reasonable and easy to add to GLib.
But a terminal by itself is fairly useless without anything running in it? I.e. do you want to launch a shell running in a terminal? Or do you want to open a terminal and then get some kind of GIO streams to write to and/or read from it? (In the latter case it is clearly a different thing that what AppInfo does, so the amount of shared code would not be that large, if I understand correctly.)
I maintain Kupfer [ http://live.gnome.org/Kupfer ] and my usecase is just implementing Directory -> Open Terminal Here as an action the user can do. At the moment I have to hardcode a list of terminals to try (starting with xdg-terminal, but it is very seldomly available). This action is relevant for applications doing the same or just the same action for different purposes (nautilus open terminal extension), gedit or an IDE -> Open Terminal in project directory. As far as I know, there is no modern API to get the user's configured Gnome Terminal. As these things go, when this is now implemented, it should get the user's configured terminal in a cross-desktop compatible way. Thank you for your interest in this bug.
two ways we could approach this one (if at all): 1a) GDesktopAppInfo * g_desktop_app_info_create_shell(void); 1b) GAppInfo * g_app_info_create_shell(void); -> on windows, could open cmd.exe 2) gboolean g_somenamespace_launch_terminal_window(GError **error); #1 has the advantage of *sort of* fitting into the existing API. it has the disadvantage that a lot of the things in GAppInfo are not really applicable -- for example, you wouldn't be able to pass any arguments to your shell. if you wanted to run a shellscript you could just run that directly, and even if you wanted to run it via the shell (maybe there is no +x on the file) it wouldn't be safe because you don't know if maybe the user has csh as their shell. the launch context stuff is almost useless for this case. the only vaguely useful thing that might apply is the DISPLAY on which to open the terminal emulator. #2 has the disadvantage of being a random chunk of API with no apparent connection to anything. also, the launch context stuff *may* be slightly useful.
My entrance point was the similarty of the task, and thus GIO should be capable to launch "bare" terminal windows. I did not realize how assimilar the task of opening a terminal window is to launching an application. Also notice that all use cases I listed want control over the working directory of the terminal, and for a big application, changing directory in the application process itself for this might be impractical (you could fork before that of course). I now acknowledge the API is a rare one, it can't really fit into the GAppInfo API. If it is implemented completely separately, the whole point gets lost though. The previously referenced xdg-terminal is a script that may open a terminal window, cross linux desktops, but it has never been part of a real xdg-utils release. Had it been available, you could just have pointed at it.
The function in GIO that detects which terminal to open is actually really simple -- it just checks (by going through a list) which one is installed in the path. You could easily copy that function to your code...
(In reply to comment #5) > The function in GIO that detects which terminal to open is actually really > simple -- it just checks (by going through a list) which one is installed in > the path. You could easily copy that function to your code... That means GIO has no ambition to use the user's configured terminal program at all, at which point I think this feature request is pointless (no disrespect, just different goals!). I need xdg-terminal, then.
*** This bug has been marked as a duplicate of bug 592857 ***