Per workspace layout settings

[itpropro]

I have two monitors and multiple workspaces. It would be great, if I could define a layout and it's settings (at least master/dwindle and basics like mfact) per workspace.
Currently this makes layouting very difficult. There is a plugin that tries to solve this (https://github.com/zakk4223/hyprWorkspaceLayouts), but I had multiple crashes and other issues using it so far.
As this is such a basic feature that is constantly asked for, it would be great to have it in Hyprland natively. It would also help users move to Hyprland coming from other layout systems.
The least we can improve here would be to have all the config options for the layouts (especially master) available as layoutopt, not only orientation.

[vaxerski]

I've answered this before somewhere else.

The reason why this is not the case is because "layout" is not just "ha split like this". Layout is like an independent WM on X, so your feature is akin to "how can I use bspwm on monitor 1 and i3 on monitor 2" which makes no sense and is not how anything here is designed.

XMonad treats layouts differently and thats why it works there.

[vaxerski]

the problem here is floating windows. Tiled would work, but floating windows physically cannot be controlled by two different layouts. What do we do about those?

[itpropro]

the problem here is floating windows. Tiled would work, but floating windows physically cannot be controlled by two different layouts. What do we do about those?

Having a limitation of not being able to move a window in a floating state to another layout, is a good compromise. But I understand your concern that there are probably multiple edge cases like this that all need to be handled to not make the users experience subjectively worse, because they expect something from a feature like this that cannot technically be achieved.
What do you think about adding more layoutopt config options for now?

[zakk4223]

the problem here is floating windows. Tiled would work, but floating windows physically cannot be controlled by two different layouts. What do we do about those?

If a floating window is fully 'inside' a workspace/screen the layout that is currently controlling that workspace wins. If the window spans multiple monitors then you just have to decide what is a reasonable threshold to transfer that control.

You could also just declare/decide that floating windows exist in a dedicated global floating layout and only interact with tiling layouts when the window transitions in/out of floating state. That might be a bit too limiting though.

Currently the existing layouts have very little interaction with floating windows anyways.

Window drag and drop across layouts is also an issue since the current model expects that the layout controls the entire operation from start to finish.

[VirtCode]

I also think that handling the floating windows in a separate way would probably be the cleanest approach. So far I did also not see a layout which actually changes the behavior of floating windows, and I also can't really think of a usecase which would.

We probably could also handle drag and drop with this "global floating layout", so as soon as the user starts to drag a window, we'd remove it from the layout (maybe inform it that it was removed for dragging) and add it to our "floating layout" as dnd. When the user drops it somewhere we add it back to the layout that is active on that workspace/monitor via a "window dropped" method or something, which also communicates the position etc.

Moving windows via the dispatcher across monitor boundaries would also have to be handled differently, so a layout would have to be able to signal to the compositor that a window should be removed from it and moved to another monitor with a possibly different layout. A similar story would be the case for swapwindow.

[vaxerski]

What do you think about adding more layoutopt config options for now?

MRs/suggestions for specific ones welcome.

In general this is something that could work, but is not something easy. I'll promote this to an issue, but won't work on it ATM.

IMHO the only way of doing this atm is:

• splitting layout inheritance into something like simplelayout and fulllayout where the latter "takes over" everything, while the former can be confined to a workspace
• fixing some window dnd funsies
• refactoring the available layouts into simple layouts

[itpropro]

For extending the layoutopt there is also #7642
I really think that most of the challenges users have with customizing the layout would be solved by exposing most or all of the layout settings via. layoutopt.
In my opinion the most impactful settings for the master layout would be mfact, slave_count_for_center_master, always_keep_position, center_master_slaves_on_right, new_status and new_on_top.

[zakk4223]

As far as adding all the layout options as workspace rule layoutopts, I think that's a good idea no matter if you have multiple layouts or not. I change my layoutopts based on monitor size.

I did something like this in nStack: https://github.com/zakk4223/hyprNStack/blob/1959ecbc50071e5e182b6ce0edff92245870caf1/nstackLayout.cpp#L50

I feel like there has to be a better way to handle this in a more global way where layout plugins could declare config options that can be overridden by workspace rules and be able to ask for them without every layout having to copy a bunch of boilerplate code to do it.

[vaxerski]

#10293 for split layouts. Anything else (layoutopts or whatever) specific FR discussions can be opened.