566865 - Define all Keyboard Shortcuts for TabCandy

Status: RESOLVED FIXED

(Firefox Graveyard :: Panorama, enhancement)

Description

[Shae Rivard [:crimius]]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3
Build Identifier: 0.3.1

On my Slack 13 setup, it seems that Ctrl+e will zoom out, however on an XP install with the same version of Firefox (3.6.3) and TabCandy (0.3.1) Ctrl+e does nothing.

Also, could we get shortcuts to for switching groups?  perhaps Ctrl+[ and ctrl+]?  I'd like to keep it to 1 meta key, but the pickin's are slim.

Reproducible: Always

Comment 1

[Ian Gilman [:iangilman]]

This appears to be two bugs filed as one. Assigning to Aza for the design bug.

Comment 2

[Aza Raskin [:aza]]

This bug is now for the the creation of keyboard shortcuts for TabCandy:

Command+[ move to the group to the left
Command+] move to the group to the right
Control+tab activate/deactivate tabcandy

Comment 3

[Aza Raskin [:aza]]

(In reply to comment #2)
And continue with Command+E being the other way to invoke tabcandy.

Comment 4

[Aza Raskin [:aza]]

The command+1 shortcut will go away when bug 574850 is fixed.

Comment 5

[Ian Gilman [:iangilman]]

ctrl+tab is currently "next tab"... I don't think we should replace that with "go to tab candy"

Comment 6

[Aza Raskin [:aza]]

As stated in bug 579197 we are moving away from Command+E. That said, we should still use

Command+[ to mean move to previous group and
Command+] to move to the next group

Comment 7

[Gordon P. Hemsley [:GPHemsley]]

(In reply to comment #6)
> As stated in bug 579197 we are moving away from Command+E. That said, we should
> still use
> 
> Command+[ to mean move to previous group and
> Command+] to move to the next group

For the record, within a regular window/tab, those commands map to forward and back. (I don't personally use them—I stick to Backspace and Shift+Backspace—but some people might, and it might be important to keep that in mind, if you aren't already.)

Comment 8

[Raymond Lee [:raymondlee]]

(In reply to comment #7)
> (In reply to comment #6)
> > As stated in bug 579197 we are moving away from Command+E. That said, we should
> > still use
> > 
> > Command+[ to mean move to previous group and
> > Command+] to move to the next group
> 
> For the record, within a regular window/tab, those commands map to forward and
> back. (I don't personally use them—I stick to Backspace and Shift+Backspace—but
> some people might, and it might be important to keep that in mind, if you
> aren't already.)


What about 

Command + { (i.e Cmd+shift+[) to previous group and
Command + } (i.e Cmd+shift+]) to the next group

Those key combinations map to move to the previous tab and next tab on Mac only, and we already have other key combinations i.e. Ctrl+tab/Ctrl+shift+tab  to do the same things

Comment 9

[Ian Gilman [:iangilman]]

(In reply to comment #7)
> For the record, within a regular window/tab, those commands map to forward and
> back. (I don't personally use them—I stick to Backspace and Shift+Backspace—but
> some people might, and it might be important to keep that in mind, if you
> aren't already.)

command+[ is the key combo for back in the Mac Finder and Safari, so it's Mac native standard for that action.

Comment 10

[Raymond Lee [:raymondlee]]

Attachment: Patch

This patch allows user to switch to previous and next group using Ctrl/Cmd + shift + [/] for now.  Once we decide what key combos to use, we can just amend them.

Comment 11

[Ian Gilman [:iangilman]]

Comment on attachment 458966 [details] [diff] [review]
Patch

Generally looks good (though I think command+shift+[ is better than command+[). I do have some critiques: 

* You should include orphans in the "no active group" path as well. 
* I think the code would be more consistent and flexible if getNextGroupTab returned a TabItem, which you then pulled the .tab.raw out of.
* looks like you're killing the #ifdef but adding a #else? Seems like you still need the #ifdef, so the #else isn't orphaned? 

So I'm approving given that those are fixed...

Comment 12

[Ian Gilman [:iangilman]]

(In reply to comment #11)
> Generally looks good (though I think command+shift+[ is better than command+[).

Whoops, misread your comment; you're already using command + shift.

Comment 13

[Ian Gilman [:iangilman]]

Comment from Kevin on the key combo for next group:

Given:
 - Key combos are for increased speed for power users
 - Key combos are faster/easier to access if keys are located near each other (for one handed use).
 - Current key combo for next tab is ctrl + tab (Mac and Win)
 - Unavailable choices are: ctrl + tab (tab navigation), alt + tab (Windows' window navigation), command + tab (Mac program navigation). 

Conclusion: 
 - Given the above, the key combo for next group should be accessible from one hand (for speed), and the left hand (for consistency with next/prev tab).
 - One logical option is: ctrl + ~ (ctrl + shift + ~ for reverse). This provides solitary, left-handed, use, without encroaching on existing browser/OS behavior.

Comment 14

[Gordon P. Hemsley [:GPHemsley]]

(In reply to comment #13)
>  - One logical option is: ctrl + ~ (ctrl + shift + ~ for reverse). This
> provides solitary, left-handed, use, without encroaching on existing browser/OS
> behavior.

I take it you're referring to Ctrl/Cmd+` (since you already have to press Shift to access ~)?

Keep in mind that Cmd+` and Cmd+Shift+` cycle through the windows of one application on a Mac. However, on Mac, Ctrl+` and Ctrl+Shift+` do not appear to do anything.

Comment 15

[Raymond Lee [:raymondlee]]

(In reply to comment #11)
> * You should include orphans in the "no active group" path as well. 
I though when there is no active group, it would mean orphaned tabs are already showing on the tabstrip.  Is there something that I miss?

Comment 16

[Raymond Lee [:raymondlee]]

Applied:
- getNextGroupTab returns a tabItem
- Use  ctrl + ~ (ctrl + shift + ~ for reverse) for all platforms
http://hg.mozilla.org/users/edward.lee_engineering.uiuc.edu/tabcandy-central/rev/ff0974f4dc11

Pending:
- include orphans in the "no active group" path?

Comment 17

[Ian Gilman [:iangilman]]

(In reply to comment #15)
> I though when there is no active group, it would mean orphaned tabs are already
> showing on the tabstrip.  Is there something that I miss?

Ah! Good point. Then I think we're good.

Comment 18

[Ian Gilman [:iangilman]]

In terms of the scope of this bug as a whole, have we properly determined all keyboard short cuts for Tab Candy, or is there more to be determined? Perhaps reassign to aza?

Comment 19

[Raymond Lee [:raymondlee]]

(In reply to comment #18)
> In terms of the scope of this bug as a whole, have we properly determined all
> keyboard short cuts for Tab Candy, or is there more to be determined? Perhaps
> reassign to aza?

I think we properly determined all short cuts.  Re-assigning to aza to see whether we have anymore to do or not.

Comment 20

[(no longer active)]

Mass moving all Tab Candy bugs from Mozilla Labs to Firefox::Tab Candy.  Filter the bugmail spam with "tabcandymassmove".

Comment 21

[Dietrich Ayala (:dietrich)]

Bumping this. Can we scope the problem down to just group-switching, and get this patch landed?

Comment 22

[Aza Raskin [:aza]]

Scoped.