Window state and dynamic resizing

[DiXN]

It would be nice to be able to resize applications by one tile with a hotkey.

For example in case of a 4x1 grid, where two application each occupy two tiles, pressing the hotkey would make one application occupy three tiles and the other one then.

I am not sure how to keep track of how many tiles each application occupies though. This could be especially difficult with more complex layouts and applications stacking on top of each other.

[tarkah]

My gut feeling is this is out of scope. I really want to keep this program simple without too many shortcuts, primarily focused on quickly resizing with the grid. As you mentioned, a lot of additional development would need to be implemented to allow tracking all windows, probably in some sort of tree-like structure.

This would push the program to need to behave more like a full blown tiling window manager. A few good alternatives exist that would give someone that level of control:

• https://github.com/prabirshrestha/dwm-win32
• https://github.com/fuhsjr00/bug.n
• https://github.com/rickbutton/workspacer

[DiXN]

I figured that this might be out of scope as well as it drives up complexity. On the other hand, the basic concept of this would not be limited to hotkeys. This also could enhance the original indented workflow with the mouse because now each application has to be resized individually, if one needs to be resized in order for all of them to be aligned again.

As to the alternatives that you mentioned, I did test all of them a little bit but none of them felt right on Windows or maybe I just did not test them enough or even used them properly. I like this window manager because it is sort of in between and therefore it felt more natural on Windows.

In the end I am also a bit conflicted on this so maybe I'll test something in my fork and see, if there is a sensible solution and furthermore see if this would be a sensible addition.

[tarkah]

I'm definitely down for trying to scope something sensible out. And if we land on something we like, we can maybe push it into a 1.0.0 release, along with some refactoring.

I think it's important we define this really well. I'll try to collect my thoughts around this and list them out in detail.

[tarkah]

So we're talking about adding a feature that tracks "certain" windows against the grid, and when one window is resized within the grid, the other windows will intelligently resize around that window. So if a window increases in size by columns, any other windows that intersect with that column need to shrink past that column. Same for the reverse and by rows.

A list of questions / concerns / thoughts:

• This feature would have to be opt-in and not the default behavior as it changes the current default behavior of the program
• What windows are eligible for tracking / dynamic resizing? I'd think it can only be windows that were previous resized via the grid, since we can track them from that initial resize action and they conform to the grid layout.
• What happens if a window that was previously tracked gets manually resized / no longer fits perfectly inside the grid layout?
• What happens when the user changes profile to a different layout / changes the columns or rows of the layout?
• How do we prioritizes which window(s) get reactively resized when a non-trivial change occurs? For example, a window shrinks by both 1 column and 1 row. Does the window below it get to increase up by one row, or does the window to the right get to increase to the left by one column?

There are probably a lot of edge cases I haven't thought of and already this seems a bit unmanageable outside of some very simple layouts. I'd be interested in your thoughts as maybe I am over complicating the original thought.

[DiXN]

Those are some valid concerns!

• I agree changing the current behavior, in order to support this would not be a good idea. Could be done with yet again another key combination to open the grid or by pressing a certain key while resizing. Kind of like how shift to select multiple works.
• Yes, this could realistically only be done with windows that already are in the grid layout. In any other case there are even more variables to consider, for example are they on the same z-level? I guess it could be done also with windows, that are not in the grid layout but would also probably require a even more "hacky" solution.
• Depending on the chosen approach, it would be resized to last known grid resize layout of the window +/- resize offset.
• I see this only problematic if the user chooses a profile that has less rows or columns, than windows currently resized with the grid. For example user has aligned 6 windows in a 3x2 grid and switches to a 2x2 grid. What happens to 2 of the 6 windows in case of a resize?
• I don't see the problem here or maybe I do not understand you correctly. Maybe this concerns the problem I thought of on how the distribution works when there are more than two windows on the x, y axis. If the tile resize amount aligns with the amount of other windows on the same axis, will each window be resized evenly. For example there are 4 windows on the x-axis and one gets enlarged by 3 tiles on the same axis, will all other windows be shrunken by one tile? And what happens if the tile resize amount does not align with the amount of other windows? Who gets priority?

The two approaches I currently thought of are:

• Tracking all windows in a data structure with id of the window, last known grid layout and what else is needed. Probably easy to implement but difficult or cumbersome to maintain properly. What happens if a window get closed, moved to a different screen and more importantly how does maintaining this structure work? By listening on changes of window events or a plain check with a timer?
• "Math" approach: No maintaining overhead, since there is no data structure. Windows will be tracked by calculating the grid layout according to their size. This approach could fall flat on many cases though, for example on a manual resize or switch of profile.

A lot of questions and things to consider for sure.