feat: persistent layout per monitor

[Truenya]

Describe your PR, what does it fix/add?

added possibility to set layout per monitor (currently only persistent)

Is there anything you want to mention? (unchecked code, possible bugs, found problems, breaking compatibility, etc.)

layouts logic needs refactoring, but it doesn't belong here in this MR

Is it ready for merging, or does it need work?

work is not done, code has 94 occurrences of getCurrentLayout, i have to add to all that occurrences passing monitor id and debug all stuff.
also, configuration is not debugged yet

[zakk4223]

#6544 ?

That said god damnit vaxry just do it

[Truenya]

#6544 ?

That said god damnit vaxry just do it

I'm sorry, I didn't completely understand you =)

I also share the opinion that linking layouts into workspaces creates an unnecessary level of complexity. But in case, when workspaces class will just contain that method, it will be really simplier to pass monitor imo

[vaxerski]

hell no. I don't know how many times I have to repeat this: The system is not made for this, this is not that simple

[zakk4223]

I'm already doing it lol

[Truenya]

hell no. I don't know how many times I have to repeat this: The system is not made for this, this is not that simple

can you please close the related issue?)

[vaxerski]

...issue? which?

[Truenya]

...issue? which?

Oh, forgot to link

#622

[vaxerski]

if a MR makes it properly, I am fine with it.

This isn't properly.

[Truenya]

if a MR makes it properly, I am fine with it.

This isn't properly.

Ofc, that's why it was marked as 'draft'.

In addition, if that task is still open, I am also open to instructions and/or advice:)

[zakk4223]

This is what I had to do for per-workspace layouts in a plugin:

https://github.com/zakk4223/hyprWorkspaceLayouts/blob/main/workspaceLayout.cpp

(I'm not implying the right solution is a big proxy layout...)

You can't just modify getCurrentLayout() to conditionally return different layouts and then call whatever function on that one. Layouts as they are implemented now expect to have a global view of all windows and may or may not be keeping internal state.

Any time an operation would cross to a different layout you have to tell the old layout to remove the window and the new one to add it. Luckily replaceWindowDataWith exists so stuff like swapwindow isn't a huge pain, you just have to swap the monitor/workspace values of the windows and then tell the layouts to replace the windows. It does require a layout Do The Right Thing in replaceWindowDataWith but I think most if not all of them do.

As you can see, window drag+drop is somewhat of a pain.

I think if you're going to do this without some global 'layout arbiter' layouts need these changes:

Any operation that moves a window across monitor bounds needs to check if the destination monitor is using a different layout and transfer ownership to it. I think this is doable using existing layout methods (remove/create and replace for swapping) but adding something like IHyprLayout::transferWindowToLayout() that handles the details (which may change in the future) is probably best.

When a window is mouse dragged you have to transfer all the dragging data to the destination layout. Again a IHyprLayout function to do this is a good idea. My plugin transfers the mouse drag stuff at the end, but you might want to do it when the window 'crosses over' to the new monitor in case there's a layout that wants to react to dragging in real time.
Alternately you could inform all visible layouts of mouse move/drag/enddrag and let them ignore it if it isn't relevant to them. That might lead to conflicts if some layouts disagree on ownership tho...

Also in my opinion if you're going to do something like this it might as well be per workspace. If you do this you get per-monitor for 'free' using workspace rules. It's really just a matter of where you track layouts (on workspaces vs on monitors).