GNOME Bugzilla – Bug 83203
Command-line option to make factory open a tab in last-used existing window
Last modified: 2021-06-10 14:30:48 UTC
When using --tab-with-profile=Default, rather than opening a new tab in the current window, it creates a new one. Please make this option do something useful. =)
It does do something useful, it creates a new tab in the window being opened. gnome-terminal --tab-with-profile=Default --tab-with-profile=Foo gives you a window with two tabs with profiles Default and Foo. It can't create a new tab in an existing window, which of the 20 terminals most of us have open would it create the tab in? "add tab to random open window"? ;-)
FWIW, Havoc, if you use tabs regularly you probably don't have 20 terminal windows open ;) This is quite useful in galeon (it is the only way for me to keep the combination of evo and galeon sane when I'm clicking on bugmail URLs) but you're right about there being an issue with choice of attachment if you are oldfashioned and use more than one terminal window at a time :)
Uh, the current window under which it is running perhaps? If I run multiple copies of GNU screen and under one of them I type from a shell "screen mutt" at a prompt, it will handily open a new virtual window under the current screen. The implementation of this is not difficult, screen merely sets an environment variable which serves the same purpose as DISPLAY in X11 and uses that to determine which session to attach to, in case there are more than one. Without this functionality, it is impossible for console applications which are capible of opening new windows to instead open new tabs in the current window (any of the ircII-based irc clients such as epic can do this, for example...) When #gnome was asked how to do this, they responded --tab-with-profile sounds like it should work, but commented that this seems not to and that I should file a bug. Given that absolutely nobody in the channel knew --tab-with-profile could not open a new tab in the same window, and a good number of them are Gnome2 developers, you have at the very least a documentation bug. And the desired functionality is still missing.
*** Bug 130067 has been marked as a duplicate of this bug. ***
Since I have been wanting this since tabbing was added, let me add my expectations in case this point of view hasn't occured to the developers yet. I have an alias, "rterm", which opens a new terminal and in it runs ssh to the requested machine. I set a profile based on the nature of my interaction with the remote machine (work-office, work-datacenter, home, unknown). What would be most useful to me is if --tab-with-profile=foo would open a tab in the most recently created window with profile foo. Perhaps what I really need to do is look into writing my own program that embeds a gnome-terminal and tells it what to open. That way I could have menus for all of the hosts I want to contact and some additional controls (e.g. kill all foo tabs; re-connect; etc). But still, doing what the documentation has always seemed to say (most recent window) would be a great start.
The --tab-with-profile option (and the --tab one) is not, and was never, intended to open a window in the last opened window. Its sole purpose is to open a new tab in the last window opened by the current _command_line_. The fact that it may mistakenly be understood in any other way is a bug in the help blurb corresponding to that option, which should be fixed---and, in fact, patches proposing alternative and better rewordings are welcome, preferably attached to a separate bug report, as befits the accepted practice of confining bug reports to one issue only. Let me note that there is no need to reinforce the idea that by writing one's own programs, one can have one's apps do pretty much anything one wants them to do: that is well understood by the audience of this bug reports. In fact, that understanding usually is accompanied by the certitude that writing a patch for an existing app is sometimes a lot less work.
*** Bug 156973 has been marked as a duplicate of this bug. ***
Here with gnome-terminal version 2.8.2 it works fine. Try this syntax: gnome-terminal \ --tab-with-profile=Choco -e "links http://www.indumex.com" \ --tab-with-profile=Fresa -e python
Trying to get this working without any knowledge of the gnome-terminal code :-)
Rats, I ended up getting distracted and porting galeon's tab interface instead. Thus now having tabs that I'm actually happy with (along the bottom of the screen, don't expand to fill the whole width). Does anyone know if there's a corresponding bug (I'm not sure if gnome-terminal wants this)?
I just ran into this. I think adding a tab to the window of currently active tab would be the most obvious thing to do.
Just in case someone doesnt realize why opening a tab in an existing gnome-terminal window is useful : Sometimes I record quite a few internet radio stations using streamtuner. Streamtuner than launches streamripper. So these are seperate commands and thus all open in their own window. With a bandwidth of > 1 MBit its really ugly to have more than 10 gnome-terminal windows open. IMHO an option --attach-to-open-window ( or similar ) would suffice to fix this bug ( and make some users happy ). To keep it sane this option would open a new window ( fallback ) if there is no or there are more than one open gnome-terminal windows.
*** Bug 550070 has been marked as a duplicate of this bug. ***
*** Bug 566990 has been marked as a duplicate of this bug. ***
If the functionality does not exist, the documentation needs to be adjusted.
Another solution would be to add a dbus command to gnome-terminal to open a new tab with a command in any existing window by its name or similar.
Created attachment 132651 [details] [review] Patch to open new tab in last opened window with --tab Heres a patch to open a new tab for --tab in the last opened window instead of the new window. I've tested similar patches for Fedora and RHEL-5 and they seem to work fine. https://bugzilla.redhat.com/show_bug.cgi?id=494730 https://bugzilla.redhat.com/show_bug.cgi?id=495704 Hopefully we can now close this after seven years ;)
Oh, forgot to mention that the patch applies against the SVN version 3434.
Created attachment 132653 [details] [review] Updated patch -- previous one failed on first invocation with --tab
Why is this categorized as an enhancement? This is clearly a bug since the functionality does not work as documented.
Created attachment 133013 [details] [review] Patch to open new tab in the currently active window with --tab This one opens the new tab in the currently active window as opposed to the last opened window in the previous patch (and as documented in --help). This is what many people seem to want. You'll have to change the --help text for this.
I've tested Siddhesh Poyarekar's patch a bit on Ubuntu 9.04 and it works great. This is exactly the functionality I was looking for. Thanks Siddhesh! Can someone review/commit his patch please?
Actually, calling terminal_app_get_active_window() to get the current window might be a bad idea because it doesn't work with global metacity / compiz keybindings. I have such a global keybinding set to "gnome-terminal --tab --geometry=150x46+100+50 --hide-menubar" but that doesn't work, not even with the patch. However, if I hit ALT-F2 and paste that same command line then it works (not sure why). I think a key binding for "open a new terminal TAB, or if no terminal is running start a new terminal window" is what most people want to be able to do (without resorting to wmctrl/xdotool hacks as they do here: http://gleamynode.net/articles/2236/ ). To do that one would have to answer Havoc's question from comment #1 in some more useful way.
Well I actually gave two possible answers for Havoc's question: 1) The last opened window, as it says in the --help 2) The currently active window For me, 1) is obvious since it is explicitly mentioned in the --help. Also Martin, don't any of the two patches work when you invoke gnome-terminal --tab through your keyboard shortcut? I don't think that terminal_app_get_active_window() not working in case of keybindings automatically makes it the wrong choice. Maybe if someone could shed light on how these bindings actually invoke applications then maybe it would make more sense.
1) is simply a misreading of the --help text; see comment 6.
Ok, here's what the help says: --tab Open a new tab in the *last-opened window* with the default profile. More than one of these options can be provided. (emphasis mine) So it is really comment 6 that is misreading the --help text. Mariano said that it was never intended to do this, but the help text says something else entirely. Yes, you can probably modify the help text and end this. But it's a feature that quite a few people seem to want. Also, it's really not all that difficult to implement. And I'm willing to pitch in, not just order around :) Martin, I see what you mean now. The patch for the currently active window does not work if none of the windows have focus, which is why the keybindings do not work. This needs more work.
Yes exactly, and I think this happens because the for loop inside terminal_app_get_active_window() only reaches terminal windows in the current process? On my box if I launch gnome-terminal twice through a compiz global keybinding I get two different processes (separate PIDs etc). The two processes are placed like this in "pstree": |-compiz---compiz.real-+-sh---gnome-terminal-+-bash | | |-bash-+-cut | | | |-grep | | | `-pstree | | |-gnome-pty-helpe | `-sh---compiz-decorato---gtk-window-deco I suppose gnome-terminal has some special way of launching itself in some cases because if I click Apps::Acccessories::Terminal I still only have two processes even though I have three separate terminal windows.
ops, the other gnome terminal was supposed to be right under gnome-pty-helper: |-compiz---compiz.real-+-sh---gnome-terminal-+-bash | | |-bash-+-cut | | | |-grep | | | `-pstree | | |-gnome-pty-helpe | | `-{gnome-terminal} | `-sh---compiz-decorato---gtk-window-deco
There should be only one gnome-terminal process per login session. The problem with the patch is that it looks for the active window using gtk_window_is_active() on all currently open windows. This will fail if none of the windows have focus, hence opening a new window. I'm looking at how we can tag windows whenever they activate so that we can then simply search based on that tag. I guess the easiest way would be to tag on the set-focus event of a window, right but I'm looking to see if I can use any of the currently registered signals so that I don't need to add more code unnecessarily.
Ah right the curly braces in pstree means it's a thread. My mistake. Are you sure "the last active window" is the desired functionality? I'd rather have it always spawn the new tabs in the same gnome-terminal window all the time. For example, right now I press CTRL-ALT-A to launch a terminal using the compiz global key binding but usually what happens is that the end of the day I have like 10 terminals open and I'm not using 9 of them (because whenever I'm in firefox etc and I want a terminal quick I just hit CTRL-ALT-A because it's the fastest way). Back when I used Microsoft Windows I had cmd.exe configured so that the old prompt was re-used (they don't even support TABs) and that behavior was fine for my purposes even though I prefer TABs. My guess is that once this is implemented I might actually end up pressing CTRL-ALT-A followed by CTRL-W to immediately close the TAB away (not sure). hmm, maybe this "TAB spam" problem would be just as bad as the "terminal window spam" problem that I had originally. Anyway, the point is... besides my "main gnome-terminal" I usually keep a few special ones that I'd like to keep in a window. For example, I have a gnome-panel launcher that points to "gnome-terminal --title=blah --geometry=150x46+100+50 --hide-menubar --command 'ssh some_hostname_here'" and I don't want any other TABs in that gnome-terminal instance. I've even set a special title on that gnome-terminal instance just so I can easily find it in the task bar (to differentiate it from the localhost terminals that I'd like to stack up in a single gnome-terminal). Sorry for the long and many comments; i'm just trying to figure out how this bug is best solved in order to satisfy as many use cases as possible.
AFAIK, Firefox opens new tab in the last active window. Pidgin opens new tab in the last opened window, so it's really anybodys take here. In the end it's up to the devs to decide what they want.
Created attachment 134961 [details] [review] Patch to open new tab in the currently active window with --tab take two Take two at trying to open the tab in the last active window. I'm setting a global current_window whenever a window gets ::focus-in-event, thus keeping track of the last active window.
Now I've tried the patch from comment #32 as well and I like it! While it doesn't give _me_ exactly what _I_ want (because if the gnome-terminal is not in focus it's not automatically raised), it makes it trivial for me to get to where I want to be using wmctrl. Now, I just set my global compiz keybinding to: gnome-terminal --tab --title="LOCAL" --geometry=150x46+100+50 --hide-menubar ; wmctrl -a LOCAL After this I get _exactly_ the behavior I want. Also I didn't see any crashes or regressions so far. This patch gets my vote for merging!
About comment 23: if the keybindings opens a new instance, that means that compiz is broken by not forwarding the dbus session bus address to the process it launches. --- The latest patch is of course broken; it crashes if you close the global_window without activating a new window (e.g. by closing from the window list applet), then try adding a new tab to it from cmd line. Plus, no global vars please. --- It seems to me that before writing a patch, one should come up with a spec about how this should behave. E.g. should the 'active window' really be the last one with focus-in-event, even if it's on another GdkDisplay, another GdkScreen on this display, on this screen but on a different monitor, or on this monitor but on a different workspace? --- About comment 26: if the past maintainer in comment 6, and the present maintainer in comment 25 say you're just misinterpreting the --help output, you ought to allow the idea that you indeed are doing so. That doesn't make the feature request in this bug report invalid, of course.
comment 23 misinterpreted thread and process as being two processes, as indicated in comment 30, so compiz is not broken. --- Yeah I was uncomfortable about the global var too but adding it to TerminalApp was not working for me. I'll look at that again. Also, could you elaborate on how you got it to crash? I tried closing the global window from the window list but it did not crash on me. Something I'm missing out I guess. Oh, and thanks for trying out the patch -- after years of no activity I was beginning to think that none of the devs were interested :) --- As I mentioned before, different apps have different behaviours on this. Firefox seems to take the active window concept I tried to code in. It will open a new tab in the last active window even if it is on a different workspace. As for whether it allows for a different screen or display, I don't know -- I'll try out and let you know. I guess what we need to look for is for the new tab to be created in the "nearest" possible window, which is why the active window makes sense. I agree that validating to see if it is on a different screen or a different display altogether may involve more work but would make it more flexible. --- I can't believe we're still arguing on the meaning of the --help text. I agree I may be misinterpreting the --help text if I try to look at it from your context, i.e. the "last window opened by this command". But the "by this command" part does not exist in the text, so for a lay man it means that it will open the tab in the last opened window, not necessarily by this command. Since neither of us are really going to budge from their viewpoints on this, I suggest we move on and actually try to get this feature in rather than argue over semantics.
Christian, I was able to reproduce the crash and I've understood why -- it will die if the last active window is closed without activating another terminal window. As for the new tab behaviour, how about this: 1) The first invocation with --tab will open a new window 2) In case of existing windows, the candidate window to open a new tab in will be chosen in this order: * Window that had the last focus and belongs to the current workspace (how do we get this? Xlib?) * Window that had the last focus and belongs to the currently active screen (default screen?) * Window that had the last focus and belongs to the currently active display (default display?) * Window that had the last focus
If it was possible to implement convention proposed by Siddhesh looks ok for me. Another possibility could be an ability to set an (optional) name of a gnome-terminal window when created from command line. That name (ID) could be used as a parameter to call for example --tab command. It would be very useful for programs like SSHMenu [1] which would like to have better control where a console is opened. (Btw, mentioned suggestion was proposed by its author - Grant McLean during an us discussion). [1] - http://sshmenu.sourceforge.net/faq/#add_tabs
I'd really like this feature as well. I currently have a metacity key binding to open a new terminal, but I'd like to open a new tab in an existing terminal instead, so that I don't need a separate key binding for that, and so that I don't need to switch to the existing terminal window first. On a related note, I'd like the ability to both open a new tab in the existing gnome-terminal window and focus/raise that window.
Regarding specifications: I personally rarely open more than one terminal window, preferring to open tabs in the same terminal window. Thus, "last focused" versus "last opened" doesn't matter much to me. Firefox uses the last focused window, and that seems to work quite well in practice. I do think the behavior Siddhesh Poyarekar in comment #36 sounds sensible. But having this feature at all, with any window selection behavior, would still prove incredibly useful.
Any updates here? Now I'm moving from metacity to ion3 tiling window manager on my netbook. ion3 is very simple and useful but only way to use gnome-terminal is opening all new terminals as tabs in main window. Patch attached to this ticket is not working with current release 2.27.91 but it's easy to fix and works fine. Is there is any possibility to fast-up finishing this patch for commiting it into main tree?
Created attachment 141475 [details] [review] patch-fixed-for-2.27.91
Just uploaded fixed patch against 2.27.91 current release
Comment on attachment 141475 [details] [review] patch-fixed-for-2.27.91 Transferring patch status to the updated patch; the review from comment 34 still applies. What I'd like to see here (apart from fixing the mentioned bugs in the patch) is to either implement reusing the 'current window' only if said window is on the same workspace, screen and display as the cmdline that wants to open the new tab, or some rationaly why we should allow windows on other workspaces/screens/displays to receive the new tab as comment 36 suggests.
(In reply to comment #43) > (From update of attachment 141475 [details] [review]) > Transferring patch status to the updated patch; the review from comment 34 > still applies. > > What I'd like to see here (apart from fixing the mentioned bugs in the patch) > is to either implement reusing the 'current window' only if said window is on > the same workspace, screen and display as the cmdline that wants to open the > new tab, or some rationaly why we should allow windows on other > workspaces/screens/displays to receive the new tab as comment 36 suggests. I could understand excluding a gnome-terminal on a different display, sure. However, a gnome-terminal on a different workspace or screen should indeed work. If I want to use a new terminal, I can always ask for that. Now, long-term it might prove nice to explicitly ask for a terminal in a particular window, named somehow. However, short-term, I'll settle for any support I can get; this would make a lot of things far easier, such as starting up a mutt or vim from another app.
just ran into this (like comment 11). vote!
I'm back :) I finally got some time to look at this again and will attach an updated patch based on the logic below: * There does not seem to be a very reliable way to find out (or maintain) what the current workspace for a window is. So the workspace criterion could be skipped * As pointed out in comment #44, it does not quite make sense to open a window in another display altogether. So we could skip that too. In the end, the spec pretty much boils down to: 1) Try the last used window in the current screen 2) Try the last used window 3) Open a new window As for the justification for opening a tab on another screen, consider a dual head system where I have all my terminals on screen 1 and I am reading some code on screen 0. I want to start working on another tab in one of the terminals on screen 1 so I do an Alt+F2 and type in gnome-terminal --tab. This should work and the tab should open on the other screen.
Created attachment 144293 [details] [review] Patch to open new tab in the last used window with --tab This one no longer uses the current_window global variable, so the crash in the previous patch is fixed too. Instead, the app->windows GList is maintained in such a way that the window with latest focus is always moved to the end of the list.
The patch is diffed against 694cec54acd6968b6eb62f8e66145aa6eecc7939
(In reply to comment #46) > 1) Try the last used window in the current screen > 2) Try the last used window > 3) Open a new window > > As for the justification for opening a tab on another screen, consider a dual > head system where I have all my terminals on screen 1 and I am reading some > code on screen 0. I want to start working on another tab in one of the > terminals on screen 1 so I do an Alt+F2 and type in gnome-terminal --tab. This > should work and the tab should open on the other screen. This sounds perfect. I have precisely this situation when working with multiple screens, and your explanation matches my expectations perfectly.
*** Bug 608312 has been marked as a duplicate of this bug. ***
The latest patch posted (by Siddehesh) has been here for 6 months and seems to fix the bug fine (which can be summarized now as: "gnome-terminal --tab" always opens a new window). Is there any problem with this patch? Otherwise, could some review & commit, please.
Comment on attachment 144293 [details] [review] Patch to open new tab in the last used window with --tab This patch still doesn't address comment 43. I don't think comment 46 makes a good argument for ignoring it.
I've just tried, with the patch, "gnome-terminal --tab" on a workspace without any terminal window, and indeed it's quite strange to have a tab appearing in a different workspace (especially as there is absolutely no clue that it appeared there)! So, to summarize, the latest patch is in the right direction but needs to look _only_ for windows in the current workspace. However, the tuple stated in comment 43 "workspace/screen/display" is too restrictive, right? If there is a window open on the same workspace but different screen, we still want to use it. So it should just be "workspace/display".
It seems I confused screen with monitor, which in X is a completely different thing. Screen refers here to the second 0 in the typical DISPLAY value ":0.0", right? So the tuple "workspace/screen/display" to distinguish compatible window to receive the tab seems fine :-) I agree with Christian that the "it's difficult" argument of comment 46 is not good enough to not pay attention to the workspace. Siddhesh, I just had a little look at it. Indeed, neither Gtk nor Gdk allow to retrieve directly info about the workspace. You might want to use libwnck (or copy the right code from it) to do it: wnck_screen_get_active_workspace() wnck_window_get(GDK_WINDOW_XID(...)) wnck_window_get_workspace() Or maybe LibUnique can be used for this.
Screen and display definitely seem crucial. However, workspace seems debatable; many people keep terminals on a separate workspace from other work, but that doesn't mean that spawning an text editor via gnome-terminal should open a new gnome-terminal window rather than a new tab in the same gnome-terminal window on the terminals workspace. Given that this issue applies to command-line usage, what about adding a command-line option to control the behavior regarding workspaces? For instance, "gnome-terminal --tab" versus "gnome-terminal --same-workspace --tab"?
It seems like this has stagnated. I'd love to see this patch go through. gnome-terminal's command-line options and startup behavior really need an overhaul and usability re-think, but just fixing this bug would dramatically improve its usability.
Created attachment 179468 [details] [review] Make gnome-terminal --tab open a tab in an existing window when applicable gnome-terminal --tab should open a tab when all of the following conditions are met: * The window in which the tab is to be opened is in the current screen * The window in which the tab is to be opened is in the current workspace Of all open gnome-terminal windows that fullfil the above criteria, the latest focussed window must be chosen. If none of the above is true, a new window should be opened instead of a tab.
Comment on attachment 179468 [details] [review] Make gnome-terminal --tab open a tab in an existing window when applicable Thanks for the updated patch. A few comments: +terminal_app_get_workspace_for_window(GdkWindow *window) Missing space before '('. + GdkAtom atom = gdk_atom_intern ("_NET_WM_DESKTOP", TRUE); Use gdk_atom_intern_static_string(). (And init on an extra line, not in the decl.) +terminal_app_get_current_workspace(void) This looks redundant; just call terminal_app_get_workspace_for_window on the root window. @@ -1707,10 +1738,13 @@ terminal_app_handle_options (TerminalApp *app, + curr_workspace = terminal_app_get_current_workspace(); I don't see how this works ? Putting that call in here will get it for the factory process, but what you really need is getting it in the calling process, and forward the argument in the HandleArguments call. And additional problem is that there's no argument for it in the HandleArguments call... so perhaps put it in a fake env var and strip that out again in the factory process? Better would be to wait after the port to G[tk]Application where you can just put that in the platform_data. +/* Maintain the window that is to accept tabs as the last in the list */ +static gboolean +terminal_app_cur_window_changed (TerminalWindow *window, + GdkEventFocus *event, + TerminalApp *app) +{ + + /* We've lost focus or we're already on top */ + if(!event->in || window == g_list_last(app->windows)->data) + return FALSE; + + app->windows = g_list_remove(app->windows, window); + app->windows = g_list_append(app->windows, window); + + return FALSE; +} I don't like this constant list updating. IMHO it would be easier to just record the timestamp from the focus-in event (into TerminalWindowPrivate), and then have terminal_app_get_current_window() find the window with the timestamp nearest to the current time. + g_signal_connect (window, "focus-in-event", + G_CALLBACK (terminal_app_cur_window_changed), app); This should be made into a class handler on TerminalWindow, then. + int win_workspace; + if (win_workspace == workspace || win_workspace == 0xffffffff) Why not use -1 here? + guint attach_window; guint attach_window : 1;
Thanks for the review. I am working on the rest of your suggestions, i.e. the ones that I have not commented on here. (In reply to comment #58) > +terminal_app_get_current_workspace(void) > This looks redundant; just call terminal_app_get_workspace_for_window on the > root window. They're two different WM hints. _NET_WM_DESKTOP works only for application windows and it gives the workspace in which the application is. _NET_CURRENT_DESKTOP works only on the root window and it gives the current workspace for the root window. > @@ -1707,10 +1738,13 @@ terminal_app_handle_options (TerminalApp *app, > + curr_workspace = terminal_app_get_current_workspace(); > > I don't see how this works ? Putting that call in here will get it for the > factory process, but what you really need is getting it in the calling process, > and forward the argument in the HandleArguments call. > And additional problem is that there's no argument for it in the > HandleArguments call... so perhaps put it in a fake env var and strip that out > again in the factory process? Better would be to wait after the port to > G[tk]Application where you can just put that in the platform_data. It works because the current workspace for root window does not depend on the application at all, whether it is the calling process or the factory. I guess the only scenario where this might make some difference is when you're trying to open windows remotely by using the DISPLAY variable. In such cases, the property should give the in-focus workspace on that display, which is what we want anyway.
Created attachment 180266 [details] [review] Rework based on suggestions in comment 58 Hi Christian, Here is a new patch with your suggestions incorporated: * Fixed coding style errors * Move focus-in related code to TerminalWindow and use timestamps * Other cosmetic changes (-1 instead of 0xffffffff, bit-fields for booleans, etc.)
Hi Christian, Does the patch look OK now or do you think it needs more work?
I still think the desktop no. setting must be transferred from the command line process to the factory, instead of just assuming the user doesn't switch desktops between the time the command line is launched and the factory receives and processes the dbus message...
Any status on this bug?
Ping?
Created attachment 209421 [details] [review] Rework patch based on comment 62 I forgot about this bz (again). Here's a new patch for this based on feedback in comment 62. I'm now getting the current workspace from the commandline and passing it on to the factory. The current workspace is not needed in case we're not using factory or if there isn't an existing instance running.
I don't use gnome-terminal anymore, so if anyone wants to pick up my patch and do further work on it then they're welcome to do so.
According to the upstream changelog, this functionality exists now: commit 35e7541292538a67571a8a29a971014a7b19fe68 Author: Christian Persch <chpe@gnome.org> Date: Thu May 3 18:29:17 2012 +0200 server: Allow opening a new tab in an existing window Any details on how to trigger this?
That commit has nothing to do with this feature.
(In reply to comment #68) > That commit has nothing to do with this feature. Oh? What feature does that commit enable, then?
Are there any issues with the patch then or can it be applied?
*** Bug 734754 has been marked as a duplicate of this bug. ***
It's not in a state to be applied as-is.
Unfortunately, last patch ( Rework patch based on comment 62 ) by Siddhesh Poyarekar is OK up to version 3.6.2 (2013-03-25) only. Seems, this is longest bug for this project (since 2002 year). Is there is any chance to adapt that patch for latest version by project maintainer? Christian please?
*** Bug 742772 has been marked as a duplicate of this bug. ***
I don't get how it's a misinterpretation of --tab. It does the same as --window, and while --window's description is correct, --tab's is clearly not. (Even if it was technically correct, so many people misunderstanding would be a good reason to rewrite it.) In the first round, I recommend just removing this option with the misleading name, or at least clarifying its description. It'd be cool to implement the feature, definitely useful for those using tabs only in a single window, although it's problematic with multiple windows. E.g. comment 57 has valid points. Also, when trying to figure which is the last-used window, I'm afraid we'll be bitten by bug 677329 / https://bugzilla.redhat.com/show_bug.cgi?id=947847 . I'm also wondering if the command should respect g-t's "Open new terminals in [Tab/Window]" setting and act accordingly.
On wayland, we don't have any way to find a suitable window since we don't get to know which workspace or monitor a window is on. So I don't think we'll implement that part of the proposal. However, on git master, I've made some improvements for --tab that allow to open a new tab in the current window when it is called from within a gnome-terminal tab, and also to obey the pref as comment 75 suggests.
> open a new tab in the current window Nice :-)
Regression: The steps in https://wiki.gnome.org/Apps/Terminal/Debugging to fire up a new instance (new app-id) no longer work from gnome-terminal: # Error creating terminal: Failed to get screen from object path /org/gnome/Terminal/screen/fcbefd3e_a5fd_42af_9b23_c7f215a3ec96 Similarly, if I start xterm from gnome-terminal, close gnome-terminal, then try to start gnome-terminal from xterm, I get: # Error creating terminal: The name :1.432 was not provided by any .service files I think the values of these new env variables should be silently ignored if they don't resolv properly.
(In reply to Egmont Koblinger from comment #78) > Regression: > > The steps in https://wiki.gnome.org/Apps/Terminal/Debugging to fire up a new > instance (new app-id) no longer work from gnome-terminal: > > # Error creating terminal: Failed to get screen from object path > /org/gnome/Terminal/screen/fcbefd3e_a5fd_42af_9b23_c7f215a3ec96 This should now be fixed on master. > Similarly, if I start xterm from gnome-terminal, close gnome-terminal, then > try to start gnome-terminal from xterm, I get: > > # Error creating terminal: The name :1.432 was not provided by any .service > files > > I think the values of these new env variables should be silently ignored if > they don't resolv properly. Should also be fixed on master now.
-- 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/gnome-terminal/-/issues/1495.