GNOME Bugzilla – Bug 730128
Tab switching keys are not passed through for tabless windows
Last modified: 2015-10-06 08:02:58 UTC
After the upgrade to gnome 3.12, Alt-1/2/3/4/etc.. stopped working. Not sure how to debug this. I'm running Debian, I've been told people on Fedora don't have this problem. Any idea?
Unless the version is >= 3.12.2, this is a dup of bug 728121.
So I was running 3.12.0, but recompiling 3.12.2 I still have the same problem.
Just adding that Alt <-/-> or Ctrl-n/p works though.
Did you restart the server after compiling 3.12.2 ?
Yep, just checked, it's displaying the correct version in the UI too.
Is this resolved now? Lionel, what do you mean by "stopped working"? :) What's your preferred behavior for these keys? They used to have dual behavior: Switched to the given tab, or if there was no such tab, emitted an escape sequence. Now they only do one or the other, depending on Preferences->Shortcuts.
I mean I'm using irssi with several tabs in it. When my gnome-terminal window only has one tab, I used to be able to switch pages in irssi in gnome-terminal 3.10. When more that one terminal tab was open, it would switch between terminal tabs, unless no terminal match the Atl-(number), in that case it would fall back to send the event to irssi (or any other program running within the terminal). That stopped working with the 3.12 version.
Indeed deactivating the shortcuts in preferences->shortcuts makes the events go back to irssi
"it would switch between terminal tabs, unless no terminal match the Atl-(number), in that case it would fall back to send the event to irssi" This is exactly the "dual" behavior that was removed, not sure if intentionally or as a side effect of refactoring. I'm not sure if it makes sense to bring back this behavior, IMO it was weird anyway - I don't know. You can choose to have Alt+number to switch g-t tabs, and press Esc followed by number to send it to irssi. Or you can configure a different hotkey for g-t tabs (e.g. Ctrl+Alt+number) and press Alt+number to send it to irssi. I hope you'll find one of these convenient enough for you.
So everything is as it should be.
(In reply to comment #9) > "it would switch between terminal tabs, unless no terminal match the > Atl-(number), in that case it would fall back to send the event to irssi" > > This is exactly the "dual" behavior that was removed, not sure if intentionally > or as a side effect of refactoring. I'm not sure if it makes sense to bring > back this behavior, IMO it was weird anyway - I don't know. I think it very much makes sense to bring it back. It's only weird if you think tabs are a thing terminals have; if you don't use tabbed terminals then you shouldn't have to pay for their keybindings.
(In reply to comment #11) > if you don't use tabbed terminals then > you shouldn't have to pay for their keybindings. If you don't use tabbed terminals, you're free to disable the corresponding shortcuts for yourself (including [Shift+]Ctrl+PageUp/Down and Shift+Ctrl+T). The "dual behavior" would only be complete if all other shortcuts also behaved that way: if they don't have an effect right now then they are forwarded to the terminal. E.g. if there's no search string yet, Shift+Ctrl+G/H should be emitted; if the terminal is fully zoomed in/out, Shift+Ctrl++/- should be emitted, etc. The "dual behavior" leads to a less consistent user experience, where the behavior inside the terminal widget depends on some random UI property. I believe it's worse than having something consistent. Just my 2 cents. YMMV.
(In reply to comment #12) > (In reply to comment #11) > > if you don't use tabbed terminals then > > you shouldn't have to pay for their keybindings. > > If you don't use tabbed terminals, you're free to disable the corresponding > shortcuts for yourself (including [Shift+]Ctrl+PageUp/Down and Shift+Ctrl+T). Well yes, once I upgraded and discovered that irssi keybindings no longer worked, and once I figured out that the keyboard shortcuts were visible neither in control center nor in the profile preferences but instead in the app menu that I still can't ever remember is a thing, disabling them is in fact what I did. > The "dual behavior" would only be complete if all other shortcuts also behaved > that way: if they don't have an effect right now then they are forwarded to the > terminal. E.g. if there's no search string yet, Shift+Ctrl+G/H should be > emitted; if the terminal is fully zoomed in/out, Shift+Ctrl++/- should be > emitted, etc. On the one hand: I'm not entirely convinced this needs to be "complete". On the other hand: yes, sure, make it completely orthogonal, that sounds perfect. > The "dual behavior" leads to a less consistent user experience, where the > behavior inside the terminal widget depends on some random UI property. I > believe it's worse than having something consistent. I'm less than persuaded that the consistency you're advocating is of greater value than consistency with my muscle memory of how gnome-terminal had worked for the past nine years. It's a terminal, I'm already expecting my interaction with the keybindings to be state-dependent, even more so than I already am expecting _every_ application's keyboard navigation to be state-dependent.
*** Bug 734644 has been marked as a duplicate of this bug. ***
Adam, I used tmux and screen on terminal, I changed tmux's windows with Alt + 1/2/3/4. It works before, after upgrade to 3.12, it can't work. I thought when there are not tabs on terminal, the terminal should send the key event to tmux, screen or issri, ..., like previous version. Thanks!
*** Bug 739991 has been marked as a duplicate of this bug. ***
Please get the older behaviour back; it's convenient to use terminal in different ways -- my screen/irssi session is in a term by itself; and for other stuff I have I use multiple tabs, and alt+<n> work exactly the way I want in each of those term windows.
Created attachment 312687 [details] [review] window: Pass tab switching keys to the terminal for tabless windows I was playing around with it today because some people couldn't live without the tab-switch passthrough. So, I am leaving this patch here in case someone finds it useful.
So this is due to the GAction's sensitivity not being set because they're unused (menus still use GtkAction)? If so, I think bug 745329 will fix this.
(In reply to Christian Persch from comment #19) > So this is due to the GAction's sensitivity not being set because they're > unused (menus still use GtkAction)? If so, I think bug 745329 will fix this. Yeah, but that will be harder for users to backport on top of the current stable branches.
Given that the GMenu port can fix the user-facing issue, do you want to restore it upstream in the stable branches?
Attachment 312687 [details] looks fine to me as a fix until the gmenu port is ready. Ok to commit it to master and 3-18.
(In reply to Christian Persch from comment #22) > Attachment 312687 [details] looks fine to me as a fix until the gmenu port > is ready. Ok to commit it to master and 3-18. Ok, thanks, Christian.