Leftwm: Several odd behaviours with focus/move and floating windows (some of them)

[VuiMuich]

When a workspace contains both floating and tiled windows I observed some weird behaviours:

• with main_and_deck layout the focus is restricted to switching between the first two items of the windows list, so when one of these is a floating window this breaks
• when a floating window covers the area where the mouse-pointer will be put by move_mouse_over it happens that the floating window catches the attempt to change the focus to the underlying tiled window
• when moving windows up/down in main_and_deck the focus stays on main but should probably move to the deck, right?
• With the layout center_main_balanced the order of the focus moving feels unnatural: it hops left-right all the time, where it probably should go through all windows on the left, then all on the right, maybe go to the center-one when switching side

Some ideas for fixes:

• keep floating windows always at the end of the list
• ignore floating windows in move_window functions, maybe with a check in common_vars
• if we agree on a new behaviour for center_main_balanced it would be probably a good chance to refactor the layout-specific logic of move and focus functions with match statements opposed to the if-else-chains they are right now.

[jwnpoh]

Hello, if I may contribute an opinion, the main and deck layout has turned out to be one of the most useful layouts I'm experiencing in LeftWM.

Use case: I'm working on something on main (Window 0), but need multiple references that I've put in the deck. So for example, I am working on Window 0 and have Window 1 next to it to reference. Occasionally I need to cross-reference to Window 2, so I cycle the deck to Window 2 and immediately continue typing with focus having remained on Window 0. I feel like changing the behaviour so that focus switches to the deck when moving windows up/down would interrupt this workflow, even though it's as minor as simply having to switch focus back to main to continue working.

[VuiMuich]

Hi, your opinion is very welcome, and I fully agree, that man_and_deck is probably the most useful layout I have ever used in any WM. I currently only use main_and_deck, monocle, center_main_balanced and left_wider_right_stack with the last two sharing probably less then 5% screentime.

I also experienced your use case and find it helpful, but believe it is not a predictable and intuitive behaviour, so I wanted to gather some opinions on that.
Lex was quite right, as he stated in another discussion, that if a behaviour is introduced (even if it's 'broken') it'll be hard to change away from it.

As a counter thought on your conclusion: with the explicit focus move needed this breaks another workflow that might be equally useful. For example you have on the main your editor for code and on the deck a bunch of windows with references some of them you regularly search in some other you regularly use to copy snippets from, a debug console and a terminal for compilation. So you see it might be equally valid to move the focus to the deck or keep it on main while cycling the deck.

The most elegant solution from a user perspective would probably be a modifier-key to either cycle with or without focus move.
On the developing and configuration side this might introduce quite a bunch of effort and might break some design concepts.

[AethanFoot]

With the cycling with main_and_deck the use case jwnpoh brought is why I made it like that. I felt this use case would be more useful and common when in this layout, as the deck would be general reference notes. Adding a separate cycling would be much more awkward (for implementation and user use as they would be using two cycling keybinds) than just switching over focus when needed. With the floating it may be safe to ignore them when grabbing the windows in the active workspace, or maybe better get the index of the second normal window when in main and deck and then restrict the array to this new index instead of just 2.
With the center main layout i feel this is just the nature of how the layout is built, to create a more "correct" focusing behaviour may be complicated.
Will look at some of these bits later once im at my pc.