cosmic-epoch
cosmic-epoch copied to clipboard
pop-os
COSMIC keyboard navigation and management system
Shortcut system for navigating around the desktop and for window management.
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.
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.
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.
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.
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.
When is Cosmic Launching ? We have been waiting for 2 years now and most of the application are outdated. Neovim is running on 0.6 while even Debian Stable has it on 0.7
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.
@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
Thanks for describing what you have, it's helpful to know. I'm sure we'll be reviewing how workspace numbering works with shortcuts.
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 ( :exclamation: 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 ( :upside_down_face: ) : 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.
(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.
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?
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?
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.
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.
- 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.
- 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.
- Have to hold down Super+X while using the arrow keys to have window swap work, which is unexpected.
Mnemonics/Keybindings/UX
- 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).
- 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).
- 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.
- 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
- 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.
- 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.
- 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.
@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?
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?
@avatar4d Sounds like a bug. You can create an issue for it.
Not a bug, but by design.
@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.
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:
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 +
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.
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!
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).
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)
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?
