Re: [gedit-list] Switching of tabs with Ctrl+Tab and "internal recency list"

[renergy <adam purkrt net>]

Bobby Jack wrote:
> 
> The key point here is that two different things are
> being discussed: the keyboard shortcut for
> tab-switching, and the implementation of a 'recency
> list' for the same. Whilst there have been many good
> arguments against the use of CTRL-TAB for
> tab-switching, we haven't heard much about the recency
> list.
> 


Hell yeah! Is there a reason not to implement the "recency-aware" tab
switching?

>From the user's viewpoint, seriously, there isn't. It's a feature that
enhances the productivity of users who appreciate it, yet does not
complicate or limit the use of gedit/GNOME for users who either don't know
about it or don't use it.

Now I'm really not shouting. I'm objecting. With valid arguments, I'd say.




For the sake of completeness, let me describe in short the "recency-aware"
switching between tabs I'm talking about. As I have said, it's a (direct)
analogue to windows switching in (e.g.) metacity with [Alt+Tab]. I'm using
Ctrl+Tab combination throughout the following description. Please substitute
"WinLogo" (or "Super") for Ctrl, if the use of Ctrl+Tab irritates you.


First, there is a "recency list" inside the editor, which is a linked list
of tabs (e.g. tab4 -> tab2 -> tab1 -> tab3). The first tab (tab4 in the
example) is the current, active tab. The precedence of the tabs in this list
is totally disconnected from the order in which the tabs are
listed/displayed on the screen.

To the actual switching: There is a concept of "switching mode",
entered/initiated with pressing and holding Ctrl and the (first) pressing of
Tab. This mode (generally speaking) lasts until Ctrl is released. Repeated
presses of Tab (in this mode) cycles through the tabs, in the order they are
stored in "recency list". Visually, the switch of tab is performed after
each press of Tab. After the tab one wants to switch into is selected/found,
Ctrl is released. That ends the "switching mode".

(let's say the user pressed Ctrl and held it, pressed and released Tab
twice, and then released Ctrl; the tab1 is now selected)

Now comes the rearrangement of the recency list (inside the editor): The
selected tab is placed on top of the list, it is pointed to the previously
first tab of the list. The place from where the new first tab was taken from
in the list is fixed (i.e. the tab pointing to new first tab is repointed to
the tab the new first tab was pointing to (generally speaking)).

(i.e. the recency list after the rearrangement looks like that: tab1 -> tab4
-> tab2 -> tab3)

Switch done.


Rationale: With this attitude, recently used tabs gets automagically grouped
near each other (in the "recency list") and are easily switched between with
just few presses of Tab. There are many cases when this is totally
practical.

The "switching mode" can also be left by pressing "Esc" key (while still
holding Ctrl). This is used to cancel the switching. It selects the initial
tab and does not change the recency-list.




This behaviour should/could even be made consistent with Ctrl+Alt+PgUp and
Ctrl+Alt+PgD. For there can also be well defined "switching mode" -
initiated by first press of Ctrl+Alt+Pgup (or PgDn) and lasting until
Ctrl+Alt is released (generally speaking). So that the user could even
combine the switches done with Ctrl+Tab and Ctrl+Alt+PgDn/PgUp (if he/she
wanted).




Sincerely,
Adam






PS: And still back to Ctrl+Tab. Ok, "getting out of the editbox" is a case
when it is required. Is there some other case when it is required (to cycle
the widgets)? I can't think of any. Then, again, I think my opinion that
Ctrl+Tab is wasted is a valid one. Is there some other reason for current
Ctrl+Tab assignment?

To the substitute of Ctrl+Tab - Why not use Shift+Tab for example to get out
of the editbox?

If one wants both directions of cycling - it would leave the editbox in the
direction, in which one "went to it". I.e. if the editbox was "entered"
(selected) with [tab], [shift]+[tab] inside the editbox would select the
next widget; on the other hand, if [shift+tab] was used to "enter" (select)
the editbox, [shift+tab] inside it would select the previous widget.


Anyway, as Bobby has said, "Super"+Tab could be used for recency-aware tab
switching.

Still I think that Ctrl+Tab should be used. GNOME could thus become a bit
more attractive for a huge group if people in the Windows world, where
Ctrl+Tab is well established combination in multi-document environment. It's
really pain in the ass when the basic keyboard shortcuts doesn't work as one
is used to.

One case from recent history, when a well established shortcut was changed:
Opera and the default shortcut for new tab. It was Ctrl+N, now it is Ctrl+T,
to make it consistent with Firefox (and now also IE7.0), i.e. to ease the
users the transition from other browsers to Opera. It was widely criticized
by current Opera users, but anyway, it is Ctrl+T now by default. Wise
change, I'd say.





But leave alone Ctrl+Tab. Repeating Bobby's standpoint, I would appreciate
to hear some arguments against implementing recency-aware tab switching
alone. So far none.
-- 
View this message in context: http://www.nabble.com/Switching-of-tabs-with-Ctrl%2BTab-and-%22internal-recency-list%22-tf3233020.html#a9032274
Sent from the Gnome - Gedit mailing list archive at Nabble.com.