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

COSMIC keyboard navigation and management system #46

Open
maria-komarova opened this issue Sep 19, 2022 · 43 comments
Open

COSMIC keyboard navigation and management system #46

maria-komarova opened this issue Sep 19, 2022 · 43 comments
Assignees

Comments

@maria-komarova
Copy link

Shortcut system for navigating around the desktop and for window management.
Shortcuts Final Proposal table

@maria-komarova maria-komarova changed the title COSMIC shortcut system COSMIC keyboard shortcut system Sep 20, 2022
@maria-komarova maria-komarova changed the title COSMIC keyboard shortcut system COSMIC keyboard navigation and management system Sep 20, 2022
@mms-pl
Copy link

mms-pl commented Oct 31, 2022

Well, this alone removes 99% of my few issues with Pop :)

@soc
Copy link

soc commented Jan 4, 2023

I'm super-happy seeing that all window operations keep using the Window key.

I absolutely hated it that in old DEs half of the ops were using Alt.

@WillyWonksters
Copy link

Has shift-super-alt-arrows been considered? I find that combination to be much more ergonomic than the shift-super-ctrl-arrows that is currently proposed for moving a window to another workspace.

@GrubBox
Copy link

GrubBox commented Jun 29, 2023

Bravo Team !

These new keymaps will allow intuitive movement of windows. This is the best feature of CosmicOS and perhaps the main reason for its popularity. KDE has a similar feature but only via a plugins and its very complex to learn. This is a sweet spot between a full blown Window manager and pre-configured DE.

@krmbzds
Copy link

krmbzds commented Jul 11, 2023

I personally prefer adjustment mode. I don't care for tiling, love vim and hate holding down modifier keys. Removing adjustment mode will break habits of existing users like me.

In Current Pop Shortcut column moving & resizing with HJKL was omitted so I assume those features will be removed as well. In that case, I think that will be a step backwards in terms of ergonomy since keeping hands in the home-row is crucial for keyboard centric workflows.

direct hotkey adjustment mode
single step (faster) multi-step (slower)
immediate feedback, no preview ability to preview before taking action
need to hold down a modifier while moving windows one hand operation after entering adjustment mode, no need to hold down modifiers to move windows
unnatural to switch between moving and resizing easy to switch between moving and resizing during adjustment since it requires a single modifier key
no HJKL for move & resize, must use arrow keys move & resize with HJKL, keep hands in home-row

Please reconsider this.

@maria-komarova
Copy link
Author

Thanks for the feedback, that's good for us to know. We're still trying to find what's best for most of our users and what better serves multiple needs so it's helpful to get this feedback.

One thing to note is that HJKL are staying for all the shortcuts. The omission is merely an accident, or rather something we take for granted by now.

@GrubBox

This comment was marked as off-topic.

@pietryszak
Copy link

How to change workspace number for every monitor separetly?

@maria-komarova
Copy link
Author

So far we were only planning to have separate numbering when displays have independent workspaces so the numbering will be automatic in this case. If we find out there is more need to have numbering system that covers all workspaces, we'll need to figure out how best to include this functionality. From what I saw in other systems, things can quickly get disorienting.

@pietryszak
Copy link

@maria-komarova So in my own i3 config file I have something like that:

  • Main workspace monitor I use meta/windows + 1,2,3..

  • Second monitor meta/windows + ctrl + 1,2,3...

Easy to remember

@maria-komarova
Copy link
Author

Thanks for describing what you have, it's helpful to know. I'm sure we'll be reviewing how workspace numbering works with shortcuts.

@oKcerG
Copy link

oKcerG commented Jan 10, 2024

This seems an improvement but I still have some questions/remarks:

My usual usage 2 screens: a laptop screen with one tabbed stack and ultrawide monitor with 2/3 tabbed stacks arranged left to right. I only use a single workspace but make heavy use of the tabs (they act as an always visible overview of my windows, workspaces hide that).

When I have a window in a stack with multiple tabs I want to move it to a stack adjacent to it, would it be possible here?
When in a stack the current move window action create a new stack between the new one and the adjacent one (after painstakingly changing the tab order of the window if I there is a lot of tabs). That's not what I usually want.
I also don't want new stacks or resizing my other existing windows when moving a window.
Would you consider a shortcut (Super-Shift-Alt + arrows ?) to move the window as a new tab in the adjacent stack?
I currently do it with the mouse but it's finicky, a keyboard shortcut to do that would be way more productive.

This allows shortcuts to be logically grouped: Ctrl as a workspace modifier, Alt as a stack modifier, Ctrl-Alt as monitor modifier, resulting in the following clear intuitive summary:

  • Super + arrows is focusing an adjacent window
    • Super-Ctrl + arrows is focusing an adjacent workspace
    • Super-Alt + arrows is focusing an adjacent stack
    • Super-Ctrl-Alt + arrows is focusing an adjacent monitor ( ❗ in your proposed change it is moving a window to an adjacent monitor, but I believe that having Super-Shift for all moving actions makes more sense and is more intuitive)
  • Super-Shift + arrows is moving a window
    • Super-Shift-Ctrl + arrows is moving a window to an adjacent workspace
    • Super-Shift-Alt + arrows is moving a window to an adjacent stack
    • Super-Shift-Ctrl-Alt + arrows is moving a window to an adjacent monitor

In this usage, Super-Shift-Alt should also tread single windows as stacks:
If my windows are arranged like this in 3 horizontal splits :
[ A | B | C ] - D - [ E - F ]
where [ A | B | C ] and [ E - F ] are stacks with respectively 3 and 2 tabbed windows and D is a single unstacked window.
When in A and doing Super-Shift-Alt + left it should result in:
[ B | C ] - [ D | A ] - [ E - F ]

For the edge cases ( 🙃 ) : alt moving when at the boundary of a workspace should move to the next workspace if there is one available, if not to the next monitor if there is one available. In both cases it should move to an existing stack if present or move it as a full size window if no existing window is in the destination. If no adjacent workspace or window is there in the move direction, splitting the current stack like regular moving seems a sensible choice.

@cozy-isaac
Copy link

(Note: I'm a former contributor so I can't guarantee that my info is 100% accurate with the current thinking-- so nothing I say is from any position of authority!)

The Super-Shift-arrow shortcuts would allow windows to move into or out of stacks, with no additional modifier needed. If you had a workspace with windows [A|B|C] - [D|E], using Super-Shift-right on Window C would create [A|B] - C - [D|E] (with C not in a stack) and if hit again would create [A|B] - [C|D|E].

There was no specific stack-related shortcut planned that would, in the example above, move windows between stacks without the middle step of having a window between the two stacks. In a way, Super-Shift can act to move windows between stacks, workspaces, and monitors, depending on where the focused window starts.

I could see cases where a specific shortcut move between stacks would be faster. for actions where you want to move a window from one stack to the far end of another stack. But, with the proposal of the Super-Shift-arrows action working as outlined, does that meet the need sufficiently? (Or, does that feel sufficient compared to current Pop!_OS shortcuts?) How does that feel?


Additional unsolicited thoughts, to examine the idea more fully:

If a new shortcut were to be added, its impact on groups might also be considered. Stacks are kind of like groups, so I imagine a new shortcut could move windows between logical groups, too. (I'm imagining columns of windows where moved windows jump to adjacent columns whereas in the original proposal they would move between columns additionally.) Personally, to me it doesn't seem like something I'd want to have another shortcut for, though. I prefer having to memorize less shortcuts and accept having to press the arrows a couple more times if the overall system is flexible enough. Curious how others feel.

@maria-komarova
Copy link
Author

Thanks for the feedback and for the suggestion @oKcerG. We've talked about the shortcuts and it seems possible to add Super+Shift+Alt+arrows to move directly to the stack. But I wanted to clarify a few things first.

As mentioned above, it is possible to move a window to the stack with Super+Shift+arrows. If you have two stacks next to each other on a laptop display, for example and try to move a window from the stack on the left to the right one, it would take hitting the shortcut with the right arrow four times to move the right-most window from the left stack to the first positioned window in the right stack. So if we add the Super+Shift+Alt+arrows it would speed up the process but result in more shortcuts. What system are you currently using? Pop!_OS 22.04? Or have you tried COSMIC shortcuts in action?

You mentioned that you don't want new stacks or resizing your other existing windows when moving a window. There would be no new stacks, but could you clarify about resizing. Are there any particular situations when resizing becomes cumbersome?

@oKcerG
Copy link

oKcerG commented Jan 12, 2024

Thank you for the answers and insightful questions!

What system are you currently using? Pop!_OS 22.04? Or have you tried COSMIC shortcuts in action?

Pop!_OS 22.04, I didn't take the time to look into how to try the new COSMIC stuff, I'll try to do that with the alpha.

The Super-Shift-arrow shortcuts would allow windows to move into or out of stacks, with no additional modifier needed. If you had a workspace with windows [A|B|C] - [D|E], using Super-Shift-right on Window C would create [A|B] - C - [D|E] (with C not in a stack) and if hit again would create [A|B] - [C|D|E].
[...] In a way, Super-Shift can act to move windows between stacks, workspaces, and monitors, depending on where the focused window starts.

Yes, I understood that, and it acts like that with the current adjustment mode in PopOS. I really don't want the intermediate state where there is three stacks : [A|B] - C - [D|E], one in the middle that I don't care for and the sizing down and then back up of the source stack is disturbing. I also don't like the fact that if I want to move A to the stack on the right I have to press right 4 times, 2 times where it ends up in states that I consider equivalent to the original one in my workflow ([ A | B | C ], [ B | A | C ], [ B | C | A]), one that I don't want (single A), and a final one that I do want.

I sometimes have 2/3 stacks of 5 windows.

But, with the proposal of the Super-Shift-arrows action working as outlined, does that meet the need sufficiently? (Or, does that feel sufficient compared to current Pop!_OS shortcuts?) How does that feel?

That doesn't feel sufficient as I explained above. It would feel cumbersome and I don't think I'll use the shortcuts altogether, I'll end up sticking with my mouse to move windows but that's a shame. That's what I do currently but I don't like it.

If a new shortcut were to be added, its impact on groups might also be considered.

Maybe yes, one could argue that someone using groups wouldn't mind the flexibility of Super-Shift and changing between layouts. There might be some ambiguous situation with a "move to adjacent group" shortcut to. What should a left move do in this situation?
image

Move it to a row with the big window? to a column? I guess the most logical would be a row since the active window is originally in a row. But that doesn't feel like the only choice someone would want.

With my proposed move to stack shortcut the choice seems clear, it would move the active window to a stack with the big window.

I prefer having to memorize less shortcuts and accept having to press the arrows a couple more times if the overall system is flexible enough. Curious how others feel.

I agree with you there.

if we add the Super+Shift+Alt+arrows it would speed up the process but result in more shortcuts.

Indeed it will, but I see it more as enabling another workflow for people like me:
I won't use nested groups, I just want to have a fixed layouts with 2 or 3 stacks side by side and be able to move windows between them easily.
If my suggestion is implemented, I will rebind Super-Shift-Alt to Super-Shift and vice versa in the rare case that I do want to use nested groups.

You mentioned that you don't want new stacks or resizing your other existing windows when moving a window. There would be no new stacks, but could you clarify about resizing. Are there any particular situations when resizing becomes cumbersome?

What I meant by new stacks was new column (which in my mind is a stack with a single window) : the C in the [A|B] - C - [D|E] transitory state mentioned by isaac-8601.
As for the resizing this is the [A|B] window column shrinking to make place for the new column with C and growing back to their original size when the C is moved to the right column. This feels jarring.

To summarize my use-case:
I want to be able to use COSMIC with a layout that stays mostly fixed once I set it up.
With my laptop on the move I don't use tiling, on my wide screen at work I have 2 columns with stacks, on my ultra-wide screen at home I have 3 columns with stacks. I want to be able to move a window from one column to the other without creating new columns.

@alapins
Copy link

alapins commented Jul 21, 2024

Trying the pre-alpha in a VM and very much like the tiling! You've created something really great, that resonates with me in a way that no videos on i3 or other tiling managers has. Had the following thoughts, in 3 categories:

Bugs

Pre-Alpha, so not sure whether these are known, but thought I'd mention them in case you hadn't run across them.

  1. Using the mouse vs the keyboard has different visual overlays, specifically group outlines are visible in keyboard but not mouse. I think seeing the groups are very helpful.
  2. Using Super+U to select a group of two windows then Super+Shift+2. Expected it to move both windows in the group, but it only moved the window I originally had focused. Not sure whether this should work or whether I shouldn't be able to use group selection outside of Move/Shift mode.
  3. Have to hold down Super+X while using the arrow keys to have window swap work, which is unexpected.

Mnemonics/Keybindings/UX

  1. Sheet above says Swap windows is Super+X. Might want to describe it as eXchanging windows (which is where I'm assuming the shortcut actually came from to keep the mnemonics clear).
  2. I'd suggest Super+Ctrl for resizing the currently selected window/group (super = windows key on most keyboards, looking to Control the size of the currently selected window, as opposed to Shifting it to a different location). I'd very much like to be able to specify the size of a window/group either in pixels directly, or as a fraction of the overall screen width/height (ex. /3 would make it 1/3 of the display width).
  3. Super+Alt or Super+Shift+Alt could then be for Alternate shift/move, i.e. between virtual desktops. If there were some keyboard shortcuts to move between groups directly, the "move to a different monitor" would be made easier; if not then they'd still be accessible using Super+Shift+arrows. I recognize this changes the current custom of using Ctrl to move workspaces, but I think it would be easier to remember.
  4. It would be nice to have some shortcuts in addition to the arrows to move things to a different location. either letters or numbers, both for groups and windows/stacks. Choosing a window/stack would move the window into that stack or create a new stack with the new and old window. To make a stack using the keyboard currently you have to go to the destination window, Super+S to make it a stack, navigate back to the original window and then move it to the new stack. Seems like stacks should be handled in the same way groups are, where each window is implicitly part of a stack, but the tab chrome for the stack doesn't show for stacks containing one element. This would also address the comment above about being able to move a window between columns without creating a new column as an intermediate step.

New Features

  1. It would be nice to be able to see minimized windows (just titles?) in the layout view, and to be able to eXchange a visible window with a non-visible window. This would allow something like stacks without the tab chrome.
  2. I'd like, when hitting Super+Shift, to see the layout overlay immediately, rather than when I hit an arrow key. Some layouts aren't immediately intuitive where the group boundaries are, and I'm not sure what the best move is to do what I want. Being able to see the landscape before moving would be helpful. This might also address the desire to have a modal layout view (perhaps with a toggle in settings to prevent new users from getting confused by it) so that hitting Super+Shift on their own would move it to the layout mode.
  3. I'd love to be able to set up a file with a layout and the programs that would go in each portion of a group/stack, a la tmux. Ideally I'd be able to save the current layout with the current programs in each slot.

@pietryszak
Copy link

@maria-komarova So in my own i3 config file I have something like that:

  • Main workspace monitor I use meta/windows + 1,2,3..

  • Second monitor meta/windows + ctrl + 1,2,3...

Easy to remember

@maria-komarova what is status of that. That shortcuts for changing workspaces for only second monitor will be added before alpha iso release?

@avatar4d
Copy link

avatar4d commented Aug 9, 2024

The overall look at feel of Cosmic Epoch is fantastic. It's truly amazing how far you've come in such a short time.

That said, I'm finding the new default workflow for moving windows with the keyboard to be inefficient. In Gnome and the current Cosmic desktop, I can snap a window to the left or right side of my monitor and then quickly move it to the opposite side with a single step.

In Cosmic Epoch, if I snap a window to one side, then try to move it to the other side, it first maximizes the window and requires a second keystroke to complete the move to the other side. This adds an extra step to move a window from one side of the monitor to the other. There is already a separate shortcut to maximize the window so this adds unnecessary extra steps. This is important for me because I move windows around with my keyboard often.

Is there a way to change this behavior or am I missing a shortcut in the documentation?

@mmstick
Copy link
Member

mmstick commented Aug 9, 2024

@avatar4d Sounds like a bug. You can create an issue for it.

@Drakulix
Copy link
Member

Drakulix commented Aug 9, 2024

@avatar4d Sounds like a bug. You can create an issue for it.

Not a bug, but by design.

@avatar4d
Copy link

avatar4d commented Aug 9, 2024

@mmstick It didn't seem like a bug to me, but rather that it was by design as indicated. I can see the logic as to why it would be implemented this way for folks not used to keyboard driven interfaces.

@Drakulix Is there a way to change this behavior, an alternative shortcut, or plans to add either in the future? As much as I want to use Cosmic Epoch as my daily driver, this just doesn't operate as I want, which I guess is like every other window manager's keyboard driven workflow.

@pietryszak
Copy link

pietryszak commented Aug 9, 2024

I see that I need to move the cursor to change a workspace by shortcut.

They should add a shortcut to move workpaces by only meta + ctrl + 1/2/3.
Such a missed opportunity to go to popos from the tilling manager like i3. But when I wanna change the workspace in the second monitor I need to move the cursor to the second monitor and then use a shortcut. Pointless
It should be like this:

It's should be like this:

Zrzut ekranu 2024-08-09 170629

@RMPR
Copy link

RMPR commented Aug 14, 2024

Thank you for making this, I am loving every minute of using Cosmic on Fedora. I am wondering if in addition to Super + 0 to switch to the last workspace we could use Super + to switch to the last workspace. An user flow could look like this: I am on workspace 2, I press Super + 4 to go to workspace 4, if I press Super + 4 again, it should bring me back to Workspace 2. Conversely, if I press Super + 2 while on workspace 2, I should be brought back to workspace 4. I am open to work on the feature if someone can point me in the right direction.

@pietryszak
Copy link

Thank you for making this, I am loving every minute of using Cosmic on Fedora. I am wondering if in addition to Super + 0 to switch to the last workspace we could use Super + to switch to the last workspace. An user flow could look like this: I am on workspace 2, I press Super + 4 to go to workspace 4, if I press Super + 4 again, it should bring me back to Workspace 2. Conversely, if I press Super + 2 while on workspace 2, I should be brought back to workspace 4. I am open to work on the feature if someone can point me in the right direction.

Super + 1, Super +2, Super + 3 .. change a workspace on monitor number one.
Super + shift + 1, Super + shift +2, Super + shift +3... change workspace on monitor number two.
Like in Sway/i3.

@anaTropeas
Copy link

changing the keyboard layout is there a keyboard shortcut ?

@leviport
Copy link
Member

@anaTropeas not yet, but there will be

@zoof
Copy link

zoof commented Aug 20, 2024

Is it possible to override default keybindings? When I try to set a keybinding that is already defined, the existing keybinding gets applied and the settings app does not detect my key press.

Otherwise, Cosmic is looking fantastic!

@nicolasdumitru
Copy link

I think that an optional modal approach to managing windows is a great idea and it could be among the features that take the new Cosmic from pretty good to great. I see that it has also been mentioned by @krmbzds for similar reasons. This is one of the strenghts of the GNOME-based Cosmic. I also think that many (Neo)vim users will likely enjoy the ability to use simpler keybindings (i.e. requiring fewer modifiers and no Super key while in the window adjustment mode) to perform a sequence of multiple changes to the window layout and the ability to have the same key do different things in different modes. Having a single mode where you have to cram all the keybindings will usually result in having either unergonomic (overly complex) or unintuitive keybindings (or both).

@mipdableep
Copy link

Hi! i hope this is the right thread for this question - is there an option to edit the keyboard shortcuts in a specific text file? (a .toml config file or something similar)

@tsloughter
Copy link

This seems to be the place to ask, sorry if I should have gone to mattermost. It sounds like there are plans for stack specific keybindings? But one I didn't see mentioned is a binding specific to switching active window in a stack that loops around instead of hopping out of the stack to other windows in the workspace. Would that be possible?

@Ravengood
Copy link

For me on POP!_OS 22.04 keyboard navigation is broken when i move a window to another workspace or display ... window focus is left behind on the workspace I left (probably focusing last active window) instead of following the window i'm moving to the new workspace (very often i need to move it further or interact with the window, but to do that i need to regain focus) ... is this a bug or a feature?

@maria-komarova
Copy link
Author

This seems to be the place to ask, sorry if I should have gone to mattermost. It sounds like there are plans for stack specific keybindings? But one I didn't see mentioned is a binding specific to switching active window in a stack that loops around instead of hopping out of the stack to other windows in the workspace. Would that be possible?

This one hasn't been planned.

@Ravengood are you using COSMIC on 22.04? And it sounds to me like a bug, the focus should be on the window you are manipulating.

@Ravengood
Copy link

Ravengood commented Oct 1, 2024

@maria-komarova the above ...

And yes .. running COSMIC on Pop!_OS 22.04

image

This only happens when "Workspaces span Displays" ... when "Displays have Seperate Workspaces" focus correctly follows the window

@Ravengood
Copy link

option to edit the keyboard shortcuts in a specific text file? (a .toml config file or something similar)

This seems to be the place to ask, sorry if I should have gone to mattermost. It sounds like there are plans for stack specific keybindings? But one I didn't see mentioned is a binding specific to switching active window in a stack that loops around instead of hopping out of the stack to other windows in the workspace. Would that be possible?

This one hasn't been planned.

@Ravengood are you using COSMIC on 22.04? And it sounds to me like a bug, the focus should be on the window you are manipulating.

@maria-komarova ... yes COSMIC on 22.04 ... should i report a new issue regarding this?

@maria-komarova
Copy link
Author

@Ravengood yes, please, unless similar issue exists already.

@leviport
Copy link
Member

@Ravengood I believe the behavior your describing matches this issue: pop-os/cosmic-workspaces-epoch#95

@Ravengood
Copy link

@Ravengood I believe the behavior your describing matches this issue: pop-os/cosmic-workspaces-epoch#95

Absolutely ... thx!

@tsloughter
Copy link

This one hasn't been planned.

Is there anywhere features are proposed that I should mention stack keybindings?

@caldiag
Copy link

caldiag commented Dec 21, 2024

i was wondering is there now a shortcut to cycle between keyboard layouts? i haven't found it yet. not having one has been a huge struggle for me since i communicate with people from different languages, family and work etc.

@mmstick
Copy link
Member

mmstick commented Dec 21, 2024

You can use the input sources applet to switch between layouts

@caldiag
Copy link

caldiag commented Dec 21, 2024

@mmstick true, though it really gets in the way a little since i have to pick up the mouse to switch layouts on a desktop that is this great for keyboard-only navigation. some systems even allow for window-specific keyboard layouts which is super cool as well. or maybe there's a way to launch the input sources applet through a keyboard shorcut? either way, i'll do with the applet for now, thanks!

@nirfse
Copy link

nirfse commented Dec 21, 2024

As a multilingual user, constant language switching is a natural part of the workflow, much like typing numbers doesn't require manual GUI applet switching - it should be seamless. I appreciate that the current functionality exists, but hope it can be made more streamlined in the future.

@maria-komarova
Copy link
Author

Super + Space shortcut is planned for input source switching.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests