-
-
Notifications
You must be signed in to change notification settings - Fork 643
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to move yabai into the future? ideas / visions / cross OS / nested layouts / new JS like action/selection language #2360
Comments
"Layouting" is very much an opinionated thing, and there is inherently nothing wrong with a plugin system like you are suggesting. I imagine it would be quite a bit of work to implement this robustly on top of the current yabai model though. With that said.. The best way I can describe the problem is that it is highly flexible, in a bad way. It works very well for daily ad-hoc usages where you use 1 or 2 (maybe even 3) windows per space and open/close windows regularly (browser, editor, terminal, video player). Anything more sophisticated and it goes out the window. I have various ideas I'd love to try do make things work very differently, but can't really implement on macOS because we are not fully in control of the window server. I have not been very interested in this kind of work for a long time, so this project is mostly in a maintenance state and has been so for a long time at this point. |
I'd be interested in your visions :-) (maybe VR and 3d :-) AFAIK:
But to be honest I'd love to see this for Windows/Linux, too :-) I came up with the following sketch thinking it through. Allow nested layouts. Then you can tabs, stacks, WMII like columns etc implemented maybe easily. So even nested Stuff Like WMiiColumns ( _, WMIIColumn( Tabs ( win ))) But there is a lot more. Eg if you make windows float in WMII it recalls which
|
#193 might be another use case for adding additional layers to manage/swap spaces on multiple displays at the same time. Cause I want to focus on a topic which might occupy 2 displays. What I noticed is that warping window west doesn't warp on second display. So you cannot move a window using warp west to the free display. With WMII this is exactly what happens. You keep moving to next column, if the screen is free it will just be added one and the window will be moved there. |
WMII behavse the following way: And the default bsp binary divisions layout doens't work for me at all. The main question is how easy is it to change the code I don't understand what 'patching dock' acutally works and how the pieces work If you use 2 displays what's limiting moving focus to the other space |
Here are 2 references to illustrate that Window managegrs on Linux and Windows https://github.com/qtile/qtile/tree/ff90e5cfae7418ad62d0accc3cb38757fca2cdb9/libqtile/layout Windows manager: |
Window managers on macOS work fairly differently to window managers on Windows and (especially) Linux. There is just no reason to take on that additional complexity for this project. Linux already has a rich ecosystem for both X11 and Wayland at this point. Windows has a fair share of choices these days as well. |
One of my favorite window managers is Forge. I recommend trialing it on a Gnome VM if you have the chance https://github.com/forge-ext/forge One of my favorite features is the ability to group windows into a set of tabs. It's really helpful when I'm working within a same application on two separate projects concurrently. |
What I'd do if I had full control is to create an "infinite grid" where each window would correspond to one tile in this grid. There would be keyboard shortcuts to manipulate the viewport of this grid (move viewport around, increase/decrease the number of visible tiles in any spatial direction), effectively pulling those windows into actual screen view. Each tile would correspond to a fullscreen window, but as you increase tiles the actual render size of the windows change to accomodate the additional windows that need to be rendered in any direction. If a window escapes screen boundaries due to min size requirements it would be rendered partially, and you could either scroll the grid into view, or have it adjust/shift the viewport automatically upon focus. |
Feels like VR/3d :-) But zooming in/out and hardware resources are not well defined eventually. But GPU rendering actually comes close because it only renders the pixels viewed. And VR even has logic to render less pixels in the outer areas of the view because the eye is less sharp there. But if you imagine 20 inkscape istances with SVG graphics and millions of lines you eventually don't want your CPU to waste energy on repainting whenever you zoom :-(. Often you have a task or an idea (a box). Then you open a window (eg browser), then you start hacking (editor). then you want to view the result (app window).. then you need to ... so this feels more like a tree to me than a grid. I played around with luajit. And I know that you can put a pointer to a struct on the stack and define a C struct definition then access the fields from lua. Luajit is small and fast and available on all important platforms. It can also be used from Python :-) There is a C# port (moonphase) for lua. So it feels like Windows, OSX, and Python (eg qtilte) to get started could be supported. I tried getting started reading all the code. I am slow. but loop.c eg has concurrency stuff built in. Can I just replace all the code in the event handlers with calling into lua and start building the window manager there? There would be one eventual drawback passing pointers from C like into lua: If you access data beyond .. you might get a crash. I use tabs mostly with shells. And the terminals I use have tabs built in. And tabs in editor. So having tabs isn't most important to me. I end up with 2 columns maybe having 8 windows and if there are more I have an attic column to move windows there.. Sometimes stacking some in float mode cycling them. That eventually is not perfect. But the cool thing is they location of the windows never changes. So I can access them by muscle memory without thinking from memory. |
@koekeishiya I haven't had the chance to try it out yet, but I found the Wayland composter niria while ago which sounds like exactly what you're describing (also 👋 I was a heavy user of chunkwm and kwm back in the day but then switched to Linux ~5 years ago. Now I'm coming back to yabai because my employer said no more Linux) |
First of all I know that I could be scripting it all up
using signals etc. But maybe it's not the best design pattern.
Imagine yabai would have layout plugins like this:
Then a wmii like or other plugin could be written to place windows the way you want.
Mostly I use EDITOR | BROWSER like here:
So there are columns, you can add windows to. Then you have different ways to display:
evenly spaces (can be changed), stack like (one is visible) or stacked with labels.
I ended up using only the stacked maximized version recalling from memory always
having 'terminal' below my editor or full screen mode if I need more.
So main question is does it make sense to allow writing layout managers as plugins
eventually adding a scripting language ?
So a plugin basically would be a selection of signals and behaviors
chosen by the user to be active for a space which once chosen to be active
rearrange the windows according to the plugins.
WMII ships with wmii menu. It allows to tab complete existing words and enter own text. Perfect for creating 'spaces with label' or reuse if it exists. What might be the easiest way to get such feature ?
The text was updated successfully, but these errors were encountered: