4 ms·
OS windows are a hindrance for any workflow needing semi-permanent layout. It's ok to place two or three monolithic apps side by side, and maybe to pull apart s
by TuringTest 2y ago
OS windows are a hindrance for any workflow needing semi-permanent layout. It's ok to place two or three monolithic apps side by side, and maybe to pull apart separate working sessions at different virtual spaces. It also requires constant bookkeping to clean up all the individual windows you no longer need.
That's very different from a spatial layout, where you can juxtapose related code elements near each other, and they remain in those places for as long as you're using them, and then get rid of all them together by closing their common container.
There have been attempts to create new, more spatial work styles on window managers, but the industry is too set in their ways on how windows should be managed, and WMs are complex beasts with many moving parts. So it's usually better to keep those experimental tools self-contained within their own window or app.
- PinkSheep 2y agoAlright, I have a mismatched setup: a 1080p and a 4K screen. No matter how you twist it, the virtual screen* will have dead zones. Self-management of a single full-screen canvas is easy (browser F11). But then I will want to use the entire physical screen estate with the editor and it'll end up re-implementing large parts of the window manager just to position the windows where they belong, rendering at the correct monitor DPI. Further, just from the shown animation I can already see the same problems you'd encounter with a lot of screen space and old style window managers: you grow tired _very fast_ of moving and resizing additional windows yourself to fit more on the screen. "Maximize (on current screen)" is the only automation step in this direction and it is decades old. Windows' "snap to edges" is a semi-manual attempt at assisted window management. * in Win32 terms, a rectangle encompassing the entire region with all visible screens