[Feature Request] Make tiling window resizing methodology more intuitive/"natural"

[kmandarin-orange]

The tiling experience in Cosmic has been great so far, but I've noticed one confusing annoyance: it feels and unnatural to manage window resizing with a grow/shrink dichotomy when they're logically the exact same action: pushing a window's edge in one of two directions. I'll add some detail on problems with the current scheme, an alternative solution, and the pros/cons of said solution.

Problems with Current Scheme

• There are two logical "layers" to resizing: choosing to "grow" or "shrink" a window. This adds cognitive load to the concept of resizing by requiring users to make an extra choice about how to resize
• All four edges of the window are modifiable at once, but rarely do users need to resize a window in all four directions
  • Additionally, it's rarely an option to edit all four edges of a window, since often the window needing resizing has one of its edges on the screen border
• Splitting the problem into "growing" and "shrinking" adds a logical division that requires users to back-translate the UX flow to their desired action. Most people[^1] think about resizing windows by making two decisions: choose an edge to modify, and choose a direction to move it in. This logic is almost the reverse of the current implementation, increasing the cognitive effort to do the common task of window resizing

Possible Solution

1. Change to a directional scheme that only affects two window edges: a horizontal and vertical edge
2. Default to selecting the bottom & right edges (unless one of those edges is against the screen edge/otherwise unable to resize, in which case the opposite edge is selected)
   1. Allows us reverse the default based on localization (e.g. bottom & left instead) for RTL languages/cultures that don't prefer LTR, but this would require some research to see if this actually makes sense to people
   2. Also allows using a single shortcut for resizing (or ideally, setting a modifier key to use with the Window Focus shortcuts)
      1. We could keep a second "invert" shortcut that would flip which edges are affected, but I'm not sure how useful that'd actually be to people, or if it'd add unnecessary complication to an intentionally simpler solution
3. Use the up/down and left/right directional keys associated with focus direction to modify the bottom/top and right/left edges respectively. This simplifies the whole process down to moving the highlighted horizontal/vertical edges with their associated directional keys
4. The help bubble that appears over the current window would show users something like:

"Resize {upper | lower} edge: {up/down keys} \n Resize {right | left} edge: {right/left keys}"

Benefits

• Much more intuitive: there's a more obvious and direct connection between users' direction input and window movement, and there are simply less variables for them to worry about.
• Allows a simpler keyboard shortcut trigger method: can be a single shortcut, or a chosen modifier key to use with the user's chosen Window Focus shortcuts
• More legible help bubble: since the text is no longer columned, the text has a much lower threshold for window width before it's broken into one-word lines or truncated
• Shouldn't be any more complex in code than the current implementation, and could be more maintainable

Drawbacks

• Technically more limiting, though I'd argue the current design is limiting in terms of the occasional spatial/directional confusion it causes
• Might require a couple more checks/logic for determining which edges to highlight
• UI might need to be altered to reflect the new logic accurately
  • The current UI could be kept nearly identical, only needing to change the arrow icons on the
  • Personally, I think it'd be ideal to have the focus outline only appear on the horizontal & vertical edge, but that'd require more design refactoring than is worth the minor benefit to keeping the appropriate edges emphasized

This is all a matter of preference of course, but I was wondering if others had felt a similar friction while using this feature. If so, exploring alternatives here would be interesting. If any of this was unclear, I can make some concept visuals to help.

[^1]: Source: "trust me bro" But really, the source is me and a few people I've talked to. I'm making some broad assumptions here, so hopefully this issue will surface other ways of thinking if my logic is off-base.

[nevdelap]

In my first few days of using cosmic, coming from i3, I started writing something like this but decided to leave it to think about more first. And every time I resize I feel that it is very unintuitive and feels very awkward. So I'm on the same page.

In i3, which I still use at work, and had used for many, many years at home as well, I have a binding for grow/shrink vertically using the up (grow) and down (shrink) keys and a binding for grow/shrink horizontally using the right (grow - because I use LTR languages) and left (shrink) keys. (If I were using an RTL language left/right would presumably make sense for grow/shrink horizontally) - acting on the currently active window.

There is no overhead once you've gotten used to this because the behaviour is always the same. The window grows or shrinks in the right direction with the same keystroke. Which border moves just depends on which borders are against an edge of the screen, or if they aren't the window grows or shrinks proportionately in place, as the windows above and below or on either side change proportionately. Floating windows would work the same way, they just wouldn't affect other windows as they changed size.

UI wise there is no need for arrows or a description to show you what is happening (and require you to think) because each arrow only does one thing always, and you don't have to think about it and specifically don't need visual indications to help you think about what you are doing because the key you are pressing that always does the same thing that you can see it is doing it already - the windows is resizing.

So this probably counts as a suggestion for a second alternative, as well as a seconding the motion there is something worth reconsidering in this specific area of the usability of cosmic.

[kmandarin-orange]

Fair point, it is all a matter of what people are used to. Glad to hear I'm not the only one noticing this!

I was afraid to pitch this as yet another alternative option for the devs to add to cosmic-settings though, since I assumed more people were used to the more common hyprland/i3/sway type of resizing, and didn't think the devs wanted to have another thing to maintain, hence the suggestion to replace the current method.

If it turns out the split is more even than I expected, maybe it'd be worth adding an option to change the resize scheme for sure. Until then, it'll be interesting to see what the broader community thinks about how this should be improved.