Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

super+tab should work like alt+tab #141

Open
Tidrek opened this issue Dec 12, 2017 · 7 comments
Open

super+tab should work like alt+tab #141

Tidrek opened this issue Dec 12, 2017 · 7 comments
Labels
Needs Design Waiting for input from the UX team

Comments

@Tidrek
Copy link

Tidrek commented Dec 12, 2017

Currently super+tab switches tabs in a circular way which is not really useful. How about making this behaviour more consistent and implement workspace switching like window switching? So, when I alt+tab, I switch to a previously active window, another alt+tab will bring that window back. If the same is implemented for workspaces it would be very convenient for fullscreen one window per workspace workflow, so that super+tab switched back and forth between current and previous workspace.

@Blast-City
Copy link

Hi.

Actually this would be cool since super+tab is kind of similar to super+right.

@cassidyjames
Copy link
Contributor

cassidyjames commented Jan 27, 2018

Ah, so we should keep track of the "previous" workspace and always go back to that one if you hit Super+Tab? How do we determine the order of all workspaces if you keep hitting Super+Tab?

Right now we order the windows in the window-switcher dock based on the order they've been focused (so the order changes in the switcher all the time), but workspaces are always shown as linear, left-to-right. I think I like the idea (being able to quickly switch back to whichever workspace you were on), but I think this could get really confusing if you keep hitting Super+Tab. I don't know what behavior would be expected in that case.

@ChristopherRogers1991
Copy link

A few notes about this:

This behavior, having the workspaces cycle most recently used, is the default in recent versions of OS X. I have personally disabled this option, opting for a static order, as have many (most? all?) of the people I've discussed it with (I'm required to use a Mac at work, and found this feature confusing, so it came up in a few discussions).

I believe the static ordering may be preferential for a few reasons:

  1. When switching windows, there is a visual indicator that displays the order of the windows being tabbed through (in elementary, this is a dock-like bar at the bottom of the screen, most other window managers display a list in the center of the screen), however, switching workspaces does not have this same indicator. This makes it very difficult to quickly cycle through workspaces, unless you already know where you're going (e.g. if the relative order is always the same). With no visual indicator, and a changing workspace order, it is easy to get lost in the list of workspaces. Users must go slowly through each workspace to find the one they are looking for; in the event that they miss it and go too far, they'll cycle through the entire list again, rather than seeing they've passed it in the list and just going backwards (since they can't see the list of what's behind or what's to come).

  2. People tend to switch workspaces less frequently than they do windows. Workspaces are often used to group windows relating to a particular task, e.g. a developer might have a an IDE and a browser with a few StackOverflow tabs open on one workspace, a workspace with their email/calendar, and a workspace with another browser window open to a sprint planning dashboard. Development, email, and sprint planning are all separate tasks the developer might work on for a few hours at a time before switching to one of the others. In this case, remembering which task they were at last is more challenging than remembering the relative order (e.g. their calendar is always to the right of their IDE, and to the left of their sprint dashboard).

For these reasons, I personally prefer the static order. That said, I recognize that there a likely workflows where this approach (re-ordering workspaces) makes sense, and that the visual indicator issue is something that could be addressed with a design change. So, if this does get implemented, I would ask that it remain possible to use either option (static or dynamic ordering), rather than the dynamic ordering replacing the static ordering.

@Blast-City
Copy link

Blast-City commented Jun 24, 2018

Hi.

I think what you're talking about is the workspace order.

That would not change. What would change is the order you view workspaces when you press super+tab. Super+left and super+right would still have the original (static) order.

While both shortcuts do basically the same thing i would remove super+tab. I find it confusing having two shortcuts doing the same thing.

The same goes for the super+s and super+down situation.

@ChristopherRogers1991
Copy link

Ah, I suppose if the actual order didn't change, so super+right/left still worked the way they do now, and the overview didn't change, changing super+tab wouldn't be too offensive.

@riklopfer
Copy link

@cassidyjames The list of workspaces to cycle through would be from most to least recently used when using Super-Tab. The workspace numbering would not change and therefore the behavior of Super-Right and -Left would not change. Nor would the behavior of Super-

@Blast-City
Copy link

Blast-City commented Jan 20, 2020

  • Open an App, switch to last workspace. Do this three times.
    Super+Tab order: 3 2 1

  • Press Super, hit Tab two times and release "Super"
    Super+Tab order: 1 3 2

  • Press Super, hit Tab one time and release "Super"
    Super+Tab order: 1 3 2

  • Press Super, hit Tab two times and release "Super"
    Super+Tab order: 2 1 3

  • Switch to the last workspace and open an additional app
    Super+Tab order: 4 2 1 3

  • Press Super, hit Tab three times and release "Super"
    Super+Tab order: 3 4 2 1

Sorry if it sounds confusing, but when I think of the the OP idea this is how I think it could work.

@lenemter lenemter added the Needs Design Waiting for input from the UX team label Sep 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs Design Waiting for input from the UX team
Projects
None yet
Development

No branches or pull requests

6 participants