[Solved] Window manager with no (or very small) minimum window size?

sebastiancarlos@lemmy.sdf.org to Linux@lemmy.ml – 29 points –

I need extremely small tiling windows, say something with only a width/height of 10px. However, by experimentation I found that my window manager Sway (and likely also i3) has a hard-coded minimum height of 60px and minimum width of 100px.

So, dear Linux gurus, do you know of a window manager with configurable minimum tiling window size? Or with no minimum at all? Bonus point for running natively on Wayland.

Edit: Found the culprit in the sway codebase:

sway/include/sway/tree/node.h

#define MIN_SANE_W 100
#define MIN_SANE_H 60

In short, I am not sane.

These constants are not used much in the codebase, so it shouldn't hurt to change it and compile from source. I will report results. Btw I opened an issue to see if they can be made configurable. Plus, some code archaeology suggests that this is not an issue in i3.

Thanks for your suggestions. Some, like Hyprland and dwl, sound promising, but I'll try to make it work with Sway first.

Why do I need this, you ask? It's a bit of a secret, but I've been working for about two years on a custom "operating system", or rather a suite of productivity tools unlike anything seen before. I'm about to finish it, but one of my last requirements to make it all click is a tiling window manager that is both extremely minimal and extremely customizable. It will eventually be released as free software for the benefit, amusement, and horror of everyone.

Also the top 20px of my screen has burn-in and I want to declare it unusable at the window manager level. You see, I use Linux not only to flex, but also to live frugally.

Edit 2: Compiling from source worked. Patch here:

diff --unified --recursive --text sway-git/include/sway/tree/node.h sway-git.new/include/sway/tree/node.h
--- sway-git/include/sway/tree/node.h	2023-10-23 19:21:15.915536904 +0200
+++ sway-git.new/include/sway/tree/node.h	2023-10-23 19:30:18.638894754 +0200
@@ -4,8 +4,8 @@
 #include 
 #include "list.h"
 
-#define MIN_SANE_W 100
-#define MIN_SANE_H 60
+#define MIN_SANE_W 20
+#define MIN_SANE_H 20
 
 struct sway_root;
 struct sway_output;
14

I haven't tried creating tiny windows, but I would imagine that it would be pretty easy for you to just install compositors on Wayland or window managers on Xorg and test it yourself.

But, bigger question -- I'm kind of curious why you're dead-set on a bunch of tiny tiled windows to the extent of being willing to disregard other functionality of the window manager or even the windowing system. Like, what is your use case? Is this some kind of automated testing system?

answered in post

For the burn-in part, I don't know about Wayland, but with X11, I'm pretty sure that you can use RANDR -- see the xrandr command -- to entirely slice part of the screen away. Like, you don't need to put dummy windows there or whatever, and that'll work with any WM.

Cool, thanks! Look like there are things like xrandr for Wayland with this functionality. the burn-in is not so bad right now but I'll keep this in mind.

Maybe you should edit a bit of it to be on top? I use kbin and it perfectly collapses everything after your code block by default. Not that I can’t view it, I can still expand it.

Pretty sure Hyprland will do this. I have seen it make some stupid small windows

I think dwm can be compiled (and is very minimal so quick to compile) with different minimum widths and heights.

there's also dwl, which is supposed to be dwm but native Wayland rather than X, but I haven't tried it out

I've ended up with windows of zero height in the past, due to some kind of obscure bug involving nvidia and unity games running in windowed mode, so I suspect the WM that comes with my DE has no minimum. It isn't tiling or Wayland-friendly, though, so no good for your use case.

(And add me to the list of people curious about what you intend to use this for.)

I think most window managers have the functionality to avoid windows occupying the space for custom bars. maybe you can make use of this.

I think xmonad has no such limitations. Not sure I got your question right. However I'm not sure it will work with wayland