Hyprland doesn't support the concept of layouts bigger than the viewport

[dawsers]

Description

I implemented a scrolling layout plugin, hyprscroller, which is based on the PaperWM, functionality, It works, but I have found a few limitations in Hyprland that prevent this kind of layouts to be at the same level of those that only span the viewport.

1. Focus and movement: Because Hyprland doesn't consider a Window may be outside of the viewport, a layout like hyrpscroller needs to implement special functions for focusing or window movement. This is not a problem, and quite easy to do, but when changing layouts, the key bindings are usually attached to those new functions, making it impossible to move around in one of the standard layouts. If Hyprland considered a Window may be outside of the viewport, I believe we could skip specific functions, and the standard movefocus would simply work.

2. Rendering a workspace: hyprscroller supports some kind of overview mode like hycov. For a scrolling layout, being able to view the complete layout is very useful for movement/focus. I had to implement the overview mode simply scaling the windows to fit the viewport. This works, but it is prone to bugs (for example, windows may become too small and crash the compositor). Scaling the borders becomes very cumbersome, etc. I tried to use CHyprRender::renderWorkspace() to render a scaled version of the workspace, similar to what other DEs do. The problem, again, is the renderer clamps anything outside of the viewport, so I can only render what is inside the monitor/viewport...which of course is not very useful.

There are other smaller annoyances, but they all come to the same fact. I don't know if there is or could be a plan to support layouts that span more than the viewport, or you guys consider this use case niche and are not interested.

Thank you for your work and any help or insights you could provide on this topic.

[vaxerski]

you could hook shouldRenderWindow and override the logic if you want to not clamp the windows, I believe.

[dawsers]

From what I see in the code, that will activate the window for rendering, but then its bounding box will be checked against the monitor's (in renderWindow and several other places). So the amount of function overriding that needs to be done would basically consist on re-wiring several functions of the renderer, which makes it a bit hard to do in a plugin, not just because of the amount of changes, but also because of the rapid development of Hyprland.

So the question is...if I were to write a PR to make changes to Hyprland and contemplate "there is life outside of the viewport", would it be considered, or is it not something you guys are interested on? It could be quite a bit of work to undertake if there is no real interest.

Thanks!

[vaxerski]

such a MR is fine by me