LRU tab switching via Ctrl-Tab

[otterbrowser]

LRU tab switching via Ctrl-Tab

[vitalif]

Window screenshot after pressing ctrl-tab: http://yourcmc.ru/wiki/images/8/8e/Otter-after-ctrl-tab.png

[Emdek]

There are no special shortcuts for tab bar yet, probably some default ones cause issues.
Generic shortcuts configuration is still work in progress.

[vitalif]

And are you planning to implement LRU? :-)
I think it's one of the most important features :-)

[Emdek]

That depends on what exactly "LRU" stands for in this context. :-D

[vitalif]

LRU is switching tabs in Least-Recently-Used order, as Alt-Tab does it for windows. (Maybe the correct term is MRU - Most Recently Used?)
That means when you press Ctrl-Tab a list of most recently used tabs pops up (Opera: http://yourcmc.ru/wiki/images/1/12/Mru-order-menu.png) and the tab that was selected previously is selected initially in that list. Each time you press Tab while holding Ctrl the next "older" tab is selected. When you release Ctrl, the browser switches to the selected tab, and it goes to the beginning of that list. So if you press Ctrl-Tab twice with LRU (MRU?), you always return back to the same tab.
I.e. NOT like in FF default and Chrome, where Ctrl-Tab is just "1 tab forward", and Ctrl-Shift-Tab is "1 tab backward". Default settings should have other hotkeys for that, for example Ctrl-PageUp/Ctrl-PageDown (standard, works in FF, but not really convenient, especially on laptops without separate PageUp/PageDown keys), or F1/F2 (convenient because they're close to the left hand that's always on the keyboard). In Opera 9 these even were just numeric 1/2 and I still use them :-)
In fact, after long time of Opera usage I don't really understand how it's possible to use a browser without MRU; in FF, it's possible via Tab Mix Plus (+ keyconfig + functions4keyconfig for hotkey configuration)... and in Chrome it's impossible at all.

[Emdek]

Ah, I would never guess that this term could be used in this context.
When I think LRU I see list of page numbers and question which one should be removed so next one could be added to cache. :-D

Well, why not, I would go for combo box to select desired behavior (just like which tab should be activated after current will be closed).
QTabBar internally stores this order (and uses it to implement behavior mentioned above) but sadly it doesn't expose it, so there will be need for custom implementation.

[srgloureiro]

I think both behaviours should work simultaneously. There should be a pair of keybindings for Tab at Left and Tab at Right; and another pair for MRU Tab and LRU Tab.

And Opera for the MRU/LRU Tab, Opera presented a list for that (Visual Studio also does this). Otter should also present it, but with an option to disable that list.

May be Ctrl+Tab and Ctrl+Shift+Tab should not be used for MRU/LRU Tabs, but for Tab at Left/ Tab at Right. Only for the sake to make Otter more similar to the existing browsers. And, in that case, we should think on another pair for MRU/LRU Tabs.

[vitalif]

Yes, keybindings for next/prev tab are of course needed. I use 1/2 or F1/F2 for this in opera. Very convenient because those keys are always close to the left hand.
But I think by default MRU should be at Ctrl[-Shift]-Tab, because it's logically correct in the usual "MDI" meaning: alt-tab switches windows via MRU, ctrl-tab switches tabs the same... Also it would be better in the sense of Otter "promoting" opera-like features :)
Anyway, the keyboard shortcuts must be configurable, that will solve all possible discrepancies in this area - those who want will just change the shortcut.

[xploSEoF]

I'd agree with vitalif in terms of the default functionality being similar to Opera's Ctrl-Tab as this is the same as almost all applications, and similar to Alt-Tab. Of course, these should all be "over-ridable" within the keyboard shortcuts.

[ersi-dnd]

This feature is not ready yet. Opera displays a tabs dialogue when you switch tabs with Ctrl+Tab. Midori has implemented it pretty closely the way Opera has it.

[Emdek]

@ersi-dnd, I know (and I'll add something like that), this is why it's not marked as done yet. ;-)

[landroni]

@Emdek

Does this report also concern single key bindings?

[Emdek]

@landroni, these are done already (1 and 2).

[landroni]

Oh, cool. What about other bindings, like z and x? They seem advertised in the context-menu, but don't do anything in 0.9.03.

[Emdek]

@landroni, there seems to be conflict somewhere:

QAction::eventFilter: Ambiguous shortcut overload: Z

It could be our fault or some widget registering it for itself out of the box (QWebView is also very greedy widget, having multiple shortcuts that usually aren't handled by proper QAction which is mighty annoying as there seems to be no way to disable them selectively without breaking other stuff).

[ersi-dnd]

@landroni Take a look inside your keyboard ini files and change them, try different things to get them to work. I personally deleted the default files completely, because some single-key shortcuts were heavily interfering (e.g. 2 was interfering with AltGr+2) while other were not working at all. It's good to build your own keyboard shortcuts from ground up so you will know what is available and what works. Not everything works, and then you can report about it. Webkit seems to be full of keybind-eating and conflicts.

[Emdek]

@ersi-dnd, yep, that AltGr issue is confirmed upstream, it seems that this code path was created on English only system. ;-)
And these not working at all most likely are eaten by QWebView, as mentioned earlier (can be verified using special pages or with all tabs closed)...
Please note that all engines will do the same, as they were created to behave that way (they are created for specific browsers usually and simple use cases benefit from hardcoded basic shortcuts)...

[Emdek]

@landroni, Z and X seems to work fine after that actions overhaul.

[landroni]

Works for me. Thanks!

[komoku]

Wouldn't this feature come "for free" with MDI? I think MDI window managers know the order in which windows were used (it's the order they use to draw them on screen, so that recent windows appear on top of older ones).

This is why with the "click on tab to minimize" option in the old Opera, if you click the active tab, you automatically go to the last recently used tab, a really good feature IMO because you dont' even need to use the keyboard to go to the last recently used tab.

[Emdek]

@komoku, not in the way we want it.
QTabBar stores that data for own purposes (to decide what to do after closing active tab) but doesn't expose it.
Also, we can't rely on it if we want to make it completely optional (not just allow to hide it).

[ersi-dnd]

Thanks for this one. Works pretty well in full screen mode and allows selecting tabs with mouse too, almost like in Opera.

The thing is that this function renders the tabbar largely obsolete, at least for those who don't need tab stacking. Therefore it would make sense to implement now #702 too :)

[Emdek]

@ersi-dnd, most of differences are intentional (maybe except lack of multi column support, hopefully someone will come up with good algorithm to handle it nicely, someday) to make it indeed a replacement for tab bar, so it won't close after mouse interaction.
I'll add some more details here, like ability to close tabs using small close button visible on hover etc.
BTW, I think it could be a good idea to allow to set a shortcut to show it directly.

#702 will be done as part of #31, current approach is unreliable and not worth adding more workarounds, it needs to be done properly.

[vitalif]

Thanks, just tested it. I have an issue - sometimes the tab switcher shows up, but it doesn't switch the tab from the current one. It seems it happens when I'm pressing ctrl and tab too fast... almost simultaneously...? Can you try and check? I can post a screencast if it helps you.

[Emdek]

@vitalif, yeah, screencast could be useful, so far I couldn't reproduce that.

[vitalif]

In fact I'm not sure it will help, but...
http://vmx.yourcmc.ru/var/screencast/otter_badswitching.flv

[Emdek]

@vitalif, I've managed to reproduce it few times, it looks like a race condition, key release event being fired before tab gets selected.

Currently I'm considering different strategy for such cases, completely skipping dialog if Control will be released sooner than ~100 milliseconds since key press event.
KWin seems to use similar strategy for Alt+Tab switcher.

[lc-guy]

1 and 2 aren't very convenient. If the previous/current tab currently has a form highlighted, ��it will not be able to switch tabs.

Why not leave ctrl-tab and ctrl-shift-tab's default behaviour? Alternatively, provide a way to make its behaviour equal to other browsers'.

[vitalif]

F1/F2 are good.
1/2 is just a habit after using Opera for a long time.)

[xploSEoF]

@lc-guy: ctrl+tab should follow the standard behaviour - switch through the tabs in "most recently used" order. This is the way alt+tab works in the OS, and ctrl+tab works in other applications (just not Chrome and Firefox).

The reason behind this is simple: Chrome and Firefox were only really designed for a dozen or so tabs, not too many to cycle through the lot. Operating systems are designed for a lot more applications at once, and most applications that have "tabs" are designed for a lot more tabs than Chrome and Firefox. As such, switching between most recently used is... logical.

Worth noting here, Opera 12.x was designed to handle a hell of a lot of tabs, and they chose the most recently used method - and it looks like Otter will follow many of the same decisions.

If you wish to cycle through the tabs in their display order, then you can override (in the keyboard shortcuts) or use 1+2.