Hyprland Minimize, Maximize, Focus not working

[Karagra]

Hello was wondering if you could add support for those features to work with hyprland?
https://github.com/hyprwm/Hyprland
I am not sure if this is even possible but I did see a feature called "special workspaces" that might be what would be used..

[LBCrion]

Oof. This is a fun one. Looking at Hyprland, it doesn't support minimize or maximize requests of the foreign toplevel protocol. It does however have it's own socket based IPC (which of course differs from that of sway), and it does have the concept of a scratchpad (special workspace) to park the windows.
The bad news is that to get minimize/maximize functionality, we'll need to implement full support for this IPC, which is a significant piece of work.
The good news is that we already support sway IPC protocol so have all the abstractions in place and it's a question plumbing another protocol into these.
The even better news is that Hyprland is one of the compositors with experimental support of ext-workspace wayland protocol which gives me a very good excuse to add support for it.

[Karagra]

Well thats good news! Thanks for the quick response

[Consolatis]

The bad news is that to get minimize/maximize functionality, we'll need to implement full support for this IPC, which is a significant piece of work.

Maybe they would instead be open to emulate the minimize and maximize requests via foreign toplevel protocol?
That would allow all panels to work instead of further fragmentation via yet another custom IPC solution.

The even better news is that Hyprland is one of the compositors with experimental support of ext-workspace wayland protocol which gives me a very good excuse to add support for it.

That would actually be nice. We (labwc) would love to implement ext-workspace if it is ever merged into wayland-protocols so having a nice panel to test our implementation would be very useful.

Edit:
Be aware though that Hyprland seems to use an older version of the protocol which has minor naming differences. It also seems expected to hide implementations of these kind of not-yet-merged protocols behind a default-off #ifdef or just have them bitrot in a PR.

[LBCrion]

I've been playing with Hyprland IPC and I can probably make the bar work with it, but there are some limitations:

1. There is no way to get current state of windows - i.e. if the bar is started after some windows are already open or the bar is restarted, there is no way to tell which windows are maximized. Once the bar is running it should be able to keep track of window states.
2. Minimizing windows will be a complex. Special workspace doesn't allow floating windows (unlike sway's scratchpad), so to minimize window we'll need to save it's geometry, change it to tiled, move it special workspace. To unminimize, we'll move back to it's original workspace, flip it to floating and restore it's geometry.
3. Using the IPC, we can probably support features currently supported for sway, but not wayland IPC - i.e. placer and pager.
   My biggest problem with testing so far has been stability, I've experienced random lockups and crashes a few times, which makes testing code difficult.

@Karagra, do you think Hyprland developers would be open to supporting maximize and minimize commands via wlr foreign toplevel protocol? Hyprland implements support for the protocol and implements support for maximize command outside of the protocol, so it should be just a matter of plumbing the two together. Minimize would be more work I guess.

[LBCrion]

@Consolatis, the older version of ext-workspace would explain why my test code failed to register the protocol. I'll play with the older version when I get a chance, but I guess it's not the best test platform for the current protocol.

[vaxerski]

Hyprland developers

thank you for recognizing my 19 personalities.

I can of course make the toplevel minimize request handled, but the most important question would be how? Can't see a good solution for such things on a tiling window manager.

We could indeed use the special workspace (i3: scratchpad) for that. The reasons why the special workspace doesn't support floating windows was mostly due to me being lazy. Floating windows there were creating a bit of code clashing with moving them around and shiz.

Regarding maximize - yeah sure that makes sense.

[vaxerski]

Be aware though that Hyprland seems to use an older version of the protocol which has minor naming differences

yeah thats what you get for protocols that aren't merged yet. Got the protocol a couple months ago and haven't touched it since.

[LBCrion]

I can of course make the toplevel minimize request handled, but the most important question would be how? Can't see a good solution for such things on a tiling window manager.
We could indeed use the special workspace (i3: scratchpad) for that. The reasons why the special workspace doesn't support floating windows was mostly due to me being lazy. Floating windows there were creating a bit of code clashing with moving them around and shiz.

I think using the special workspace is the most sensible solution in the tiling world. That's what most users use in lieu of minimzie. Simply binding the minimize request to move to special workspace action and uniminize to move back to the original workspace should do the trick. (but of course would need some way of moving floating windows to special workspace).

Regarding maximize - yeah sure that makes sense.

While on this topic, would it be possible to add window state info to IPC /clients request? I.e. information on whether the window is focused, maximized or minimized (if supported) or fullscreen.

[LBCrion]

Be aware though that Hyprland seems to use an older version of the protocol which has minor naming differences

yeah thats what you get for protocols that aren't merged yet. Got the protocol a couple months ago and haven't touched it since.

This is understandable and expected. I don't expect to maintain any code I write for this until the protocol is merged either.

[LBCrion]

@Karagra, I pushed initial hyprland IPC support into main git branch. At this point it loads the window list and follows focus, but non of the actions are working yet.

[vaxerski]

Hyprland now handles the maximize requests hyprwm/Hyprland@ead0e74

I'll try to get the floating windows working when I have some time if I don't forget.

[LBCrion]

Hyprland now handles the maximize requests hyprwm/Hyprland@ead0e74
@vaxerski, Nice!

I'll try to get the floating windows working when I have some time if I don't forget.
Oddly, this seems to already work for me.

Current git version of sfwbar has hyprland IPC support for window operations. It can track window states and handle focus, close, minimize/unminimize and maximize/unmaximize commands. Minimized is handled by moving the window to the special workspace.

The bits that are missing:

1. The initial fullscreen state of the windows: sfwbar assumes that none of the windows already open are maximized.
2. tracking of minimized state on silent moves. I track the movewindow event to check when a window moves to the special workspace, but this isn't emitted if the window is moved using movetoworkspaceilent command.

Next to implement is support for the pager and window placement engine.

[vaxerski]

The initial fullscreen state of the windows: sfwbar assumes that none of the windows already open are maximized.

If you mean "open before sfwbar was launched", gotchu: hyprwm/Hyprland@ff4c22c

tracking of minimized state on silent moves. I track the movewindow event to check when a window moves to the special workspace, but this isn't emitted if the window is moved using movetoworkspaceilent command.

Oops, gotchu: hyprwm/Hyprland@bdd9680

Next to implement is support for the pager and window placement engine.

Lmk if I can help with anything on the Hyprland side. For moving and resizing, you have the moveactive and resizeactive dispatchers that also take exact values if needed (e.g. exact 1280 720)

[LBCrion]

@vaxerski , thank you!
And while it's Christmas, would it be possible to get active and visible workspaces via ipc? Probably best to include these in workspaces request. I.e. "active" boolean for currently selected workspace and "visible" boolean for workspaces currently visible on all monitors.

[vaxerski]

it's already in the monitors request though