Save restore dwindle layout

[Natr1x]

Describe your PR, what does it fix/add?

To make it possible to save and restore dwindle workspace layouts via hyprctl.

To be able to "restore" layouts it adds an "opennexton" layoutmsg handler for the dwindle layout. It works like "preselect" but with a dwindle node instead.

"Saving" layouts is done with hyprctl layoutdata workspaceinfo <workspace_id>.

The hyprctl cmd ("layoutdata") which kind of does the same thing as "dispatch layoutmsg" but allows the layout to send a response. workspaceinfo is then a handler implemented for the dwindle layout.

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

Some points which need to be discussed:

• The format of the first argument to the opennexton layoutmsg handler may not be particularly intuitive. I think there should be a way to target nodes which contain more than one window. And targeting the root is really useful if you want to do something like "maximize to half the screen". But it may be better to just leave out that functionality for now.
• The names "layoutdata" and "workspaceinfo" for the new hyprctl cmd should probably be something else. (Especially "layoutdata"). I don't like that a new hyprctl command was needed to begin with but I don't see how else you would do it.
• Something like a "setnodesplitratio" layoutmsg handler is also needed if you want to restore the window sizes of the layout. I thought dispatch splitratio could be used it does not take a window argument. And even if it did there would be no way to target nodes which are not single windows.
• Master layout? This is currently only for the dwindle layout and I don't see how it could be done in a generic way which would work with every possible layout. But if we are adding a new layout specific hyprctl command then maybe we should implement at least the "workspaceinfo" handler for the master layout as well.

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

NO, the questions above need to be addressed first. But aside from that there is also the documentation and stuff like tab completions for hyprctl.

[vaxerski]

How would this be used, exactly?

[Cool-Game-Dev]

How would this be used, exactly?

Personally, I like to have my windows in a specific arrangement when I'm working, and I hate having to remake the layout every time, so that's how I would use it.

[zakk4223]

It's not entirely clear to me how restoring is supposed to work with this?

There's some utility to making this generic (i.e a matching 'restore your state from this dump you provided earlier' dispatcher). Being able to do stuff like gather all windows on a workspace into a tabbed group and then 'release' them back into the layout with the same exact positioning as before would be one use for a generic save/restore.

Unfortunately I don't think there's a good way to do this without requiring every layout to contain a json parser....

[vaxerski]

that would be understandable but I am asking in this MR, specifically, cuz I fail to see it

[Natr1x]

How would this be used, exactly?

Let's say I have a workspace where I keep all of my open chat/communication clients (discord, steam, email, etc). And I have them laid out in my own preferred way (discord always on top of steam chat in a vertical split or something).

Now say I want to temporarily focus on one of these clients in another workspace which I am currently focusing. This can easily be done with something like hyprctl dispatch movetoworkspace m+0, address:<discord window address>. And I already have my own script for doing this that allows me to select a window using tofi.

But then when I am done with the window I want to send it back to where I want it inside of my chat workspace (on top of steam). Currently there is no way to do this but with opennexton it would be possible to do something like this:

hyprctl dispatch --batch 'layoutmsg preselect t ; layoutmsg opennexton . address:<steam chat window address> ; movetoworkspacesilent name:Chat, address:<discord window address>'

If we also add layoutmsg setnodesplitratio (something I have not implemented in this MR yet) you would be able to set up a dwindle workspace according to any layout you want via the hyprctl batch commands.

I thought that together with hyprctl -j clients this would allow me to write my own script for saving and restoring sessions. Unfortunately hyprctl -j clients does not contain enough information to determine the dwindle node tree.

Which is why I added the hyprctl layoutdata workspaceinfo command. Which for the dwindle layout prints the current node tree of a workspace.

It's not entirely clear to me how restoring is supposed to work with this?

There's some utility to making this generic (i.e a matching 'restore your state from this dump you provided earlier' dispatcher). Being able to do stuff like gather all windows on a workspace into a tabbed group and then 'release' them back into the layout with the same exact positioning as before would be one use for a generic save/restore.

Unfortunately I don't think there's a good way to do this without requiring every layout to contain a json parser....

The idea is that the layouts would not have to be responsible for saving or restoring anything. Merely to have a way to be queried for layout specific state information. It would be up to the users or tool authors to make use of this information if they want to restore a session.

I'm also not advocating for this to be a requirement either. Merely for layout authors to have the option to implement custom queries the same ways they have a proper way to implement dispatch commands via layoutmsg.