Hyprland
Hyprland copied to clipboard
Standalone Monocle Layout
Main reason is to view status bars. Fullscreen provides a monocle experience but in the process takes over the space for status bars.
Moving eww over to the overlay layer keeps it shown everywhere, but it no longer reserves any space even with :exclusive.
I do not think any window rule allows this to happen (preserve reserved space by other windows in fullscreen).
You'll want to try using "hyprctl dispatch fullscreen 1" on a floating window and it should keep the status bar visible while remaining in fullscreen mode. I just verified it now using qutebrowser (once made floating) but it didn't seem to affect it when tiled.
Nice, that gets it closer. Introduces a problem when you actually try to enter fullscreen though, i.e. on a video player.
I rather think that is actually a bug instead of actually working like that.
I'll eventually look at the codebase to give it a stab at implementing myself since this is a layout I do quite need to go about... just a couple few windows of a browser but just sticking it out there in case it is easy to implement (though I'm not sure how intertwined layouts are in wayland given that there are only 2 still).
no_gaps_when_only + one group?
Moving eww over to the overlay layer keeps it shown everywhere, but it no longer reserves any space even with :exclusive.
set custom reserved area?
One group will provide a standalone monocle layout. It is not compatible with cyclenext and swapnext (with changegroupactive being a replacement for cyclenext and swapnext not having any equivalent from the dispatchers).
If I am interpreting the custom reserved area correctly, that will mean it will still be reserved when I really want fullscreen, i.e. watching a movie.
For my intents togglegroup will be enough to mimic my daily workflow from Xorg tiling managers (should be covered by monocle and dwindle), I will not be mixing groups with non-monocle layouts so binding changegroupactive to the same action I have for cyclenext should work without issue.
I'm still looking into the docs to figure out the best way to move all windows in the workspace into or out of a group but it should be possible whether I have to define a plugin or invoke hyprctl (looks like I found https://github.com/hyprwm/Hyprland/issues/1994 which I can either use as a reference).
If I am interpreting the custom reserved area correctly, that will mean it will still be reserved when I really want fullscreen, i.e. watching a movie.
No. It works like a bar, but for bars that don't do that by themselves.
I will not be mixing groups with non-monocle layouts so binding changegroupactive to the same action I have for cyclenext should work without issue.
You can write a simple script for this
This is the only feature that I'm using on dwm that's missing, everything else is there. fullscreen, 1 is not the same.
This is the only feature that is keeping me from switching from awesome wm. I'd love to have a native hyprland monocle implementation.
absolutely, this is feature that is essential for most of my workflows
I miss the different margin values for monocle mode from my BSPWM days. I want a larger margin for monocle mode
Also, if we're doing feature requests, I would also like something like the Stage Manager feature from MacOS where the non-visible windows are "minimized" to the side or bottom when we're in this monocle mode with small thumbnails. It is sort of like a master layout with the master centered but the slave windows don't resize (resizing messes up the content rendering within the window).
@vaxerski sorry for pinging, any thoughts about implementing this?
Edit: Actually hyprctl dispatch fullscreen 1 works for my usecase, still a standard monocle layout would be much cooler.
my thoughts? "No, write a plugin?"
my thoughts? “No, should I write a plugin?”
all tiled WMs I worked with before using DWL (DWM, Xmonad) have Monocle mode (in Haskell's full screen mode). IMHO, this behavior should be added to the main mode and given the opportunity to choose.
I use many monitors every day, one in the center is always in Monocle, the rest switch to the Tile layout.
At home, I use one large 60-inch monitor with customizable workspaces set to Monocle or Tile mode (if I need to see more than one window). And this workplace is widespread among my friends...
why not make a windowrule to maximize every tiled window? would behave the same I believe
why not make a windowrule to maximize every tiled window? would behave the same I believe
Do you have an example of these settings? I'll try to compare the user experience with Hypr and, for example, DWM with Monocle.
this code from dwm.c
#define ISVISIBLE(C) ((C->tags & C->mon->tagset[C->mon->seltags]))
void
monocle(Monitor *m)
{
unsigned int n = 0;
Client *c;
for (c = m->clients; c; c = c->next)
if (ISVISIBLE(c))
n++;
if (n > 0) /* override layout symbol */
snprintf(m->ltsymbol, sizeof m->ltsymbol, "[%d]", n);
for (c = nexttiled(m->clients); c; c = nexttiled(c->next))
resize(c, m->wx, m->wy, m->ww - 2 * c->bw, m->wh - 2 * c->bw, 0);
}
It would be nice to have monocle tabbed orientation for master layout
Just realized I never posted what I use, I'm not sure if this all the configuration but it looks right by this comment I left there, the following works in 99% of cases - the most glaring issue is that it is still virtually tiled, so switching windows always imposes a resize operation - which is an sometimes an annoying delay to wait for.
Full screen should be able to take over any reserved space.
# Reset the layouts on the current workspace to default (monocle-ish)
bind = $mainMod SHIFT, space, exec, hyprctl dispatch fullscreen 1
bind = $mainMod SHIFT, space, exec, togglegroup
the most glaring issue is that it is still virtually tiled, so switching windows always imposes a resize operation - which is an sometimes an annoying delay to wait for.
Yes... the animation when switching windows after setting "fullscreen 1" is annoying, specially because it actually does make some windows change the content/internal layout as they are being resized, it adds delays and the repositioning can be confusing.
I was expecting to be able to get rid of this form of animation tweaking the Animations configuration, but I did not manage to find which setting would I need to set to disable this. Does anybody know?
This is all a very awkward workaround. A monocle style layout being properly supported would be best.
I made a monocle layout: https://github.com/zakk4223/hyprlandMonocle
The layout sets all windows to the monitor/workspace size, honoring reserved space. The currently focused window is set to maximized. This is to work around the fact you cannot have overlapping tiled windows in Hyprland without introducing focus issues.
Setting the window sizes to the maximized size should prevent resizing apps on window switching.
You can navigate between windows using Hyprland's standard cyclenext or movefocus dispatchers.
If you want to run monocle only on one workspace/monitor, see: https://github.com/zakk4223/hyprWorkspaceLayouts
@zakk4223 Thanks for the plugin, but I think one of the biggest advantages of the monocle layout in other window managers is the ability to toggle the layout between a tile layout and a monocle layout that mirrors the position of the windows. So unfortunately your plugin has no usecase for me.
Check out this video on how it works in xmonad. Imo this is the perfect implementation of the monocle layout, it mirrors the window position and has tabs as well. The monocle layout also works in a similar way in AwesomeWM and DWM.
https://github.com/hyprwm/Hyprland/assets/103893901/ab30c428-89d3-4727-9af1-5da2cd8c6ae0
I think in Hyprland it would be preferable to implement it as another master layout orientation, but I don't have idea how to make it work also with dwindle layout.
looks like a fullscreen group with extra steps
Using a group for this has issues:
-
windows in groups cannot be navigated with the normal dispatchers (cyclenext, etc). You have to switch to the group navigation ones. I guess you could do some submap twiddling, but now you have to track which layout is active, you have to deal with the active workspace being changed etc.
-
if you want to gather all windows on the current workspace into a group you have to...I guess write a shell script?
Either of these are probably manageable if you're using stock Hyprland, but if you're using extra layouts, per workspace/monitor layouts etc it's not going to be as easy to do.
You can dynamically switch to this monocle layout if you use my workspacelayout plugin and bind a key to send the 'layoutmsg setlayout monocle' dispatch. (I think I have some ideas to make layout switching better in that plugin too...). However you still have the window order issue...
I don't think the 'preserving window order' thing is doable in Hyprland without each individual layout being forced to implement monocle themselves. Layouts can have an internal concept of window order. They can manipulate hyprland's window order to some degree but none of them currently do this.
I thought so that preserving window order for each separate layout is not doable, so that's why I proposed that maybe the monocle layout should be the orientation for the master layout, just like the centeredmaster layout is called orientation center in hyprland.
And as for the replicating monocle layout with groups. Someone created a script that gathers all the windows in the workspace into a group. It does it in a kinda hacky way because in the current moment there is no possibility to add windows to group by address so they are added with directional dispatchers. https://gist.github.com/Atrate/b08c5b67172abafa5e7286f4a952ca4d#file-hyprtabs-sh
Of course the biggest weakness of this script is that it doesn't preserve the window order when toggling and untoggling the group.