edit 1: accidentally a word
edit 2: I'm at a loss at why this isn't considered a contribution to the conversation. Can anyone enlighten me?
These tiny projects are often cursed by having very few resources when something goes wrong.
I'm after a 'window manager' that can help me load a single X application on top of an X session that can sense the size of the screen and render the window maximised.
If you try something like
startx /usr/bin/chromium --kiosk
If you want to write it yourself in C using Xlib, you can use the 'XMoveResizeWindow' function. You could use 'XGetWindowAttributes' to get the size of the root window.
I'm just not sure if you need a window manager to handle the dialog windows. If you do, I would just use Blackbox.
As the other commenters have pointed out, the simplest and most robust thing might be to just resize all new windows to max and map them. Now you just have to make sure that only one window will be opened...
Another story, I've been an icewm user for many years and I absolutely loved it. But at some point the bitrot was too much. Windows that didn't gain focus because of newer unimplemented client<->WM protocols, clients that crashed for hard to debug reasons, and so on. There are still some patches being developed for icewm that try to make it work with some newer clients. And there are workarounds on top of workarounds for fighting with Java clients, but at some point I decided it was too buggy and switched.
Writing a window manager could be such a nice project if wouldn't mean implementing terrible but necessary protocols, and fighting with all the bad X11 clients out there.
That's something that bothers me about wayland. There really is a lot of variance when it comes to people's preferences about window decorations and focus behavior and so on. Having the applications handle it themselves is going to result in a lot of lost functionality/configurabilty.
The new Gnome apps for instance don't respect standard interaction even when the window manager is Gnome. (For instance, if a window has a modal dialog box open, you can't move the window; I think I've also had issues with pushing windows back despite this being a configuration option.)
If you use Chromium too, it doesn't respect your settings for where the minimise/maximise/close etc buttons go until you right click somewhere and say "let me forget that your developers think they're so special they have to remind me i'm using your app every time i want to immerse myself".
Gnome people will probably say "it's a trivial bug which we will fix shortly". But in reality it's intrinsic to the design. Now instead of picking an application which does its job well and a window manager which does its job well, you have to pick an application which manages its own windows well and does its job well. All because someone thought it's prettier if title bars have menu bars in them.
The push to make everything electron just means that everyone else is having this problem now.
Any chance anyone knows of something similar to this but using Wayland as opposed to X?
Do you have any pointers to getting started developing for with Wayland (and wlroot)?
ps. Thanks for creating/maintaining Sway! it's great stuff! ds.
And I'm glad you like sway :)
While I have been busy and will be busy for a few more months I look very much forward to working through your posts and learning something about wayland and sway then :)
also kudos :)
Well yes and no. A wayland compositor has to blit the images of the applications which need to draw themselves into buffers. At least that's my understanding of it. The compositor isn't supposed to draw anything, it just copies things to the frame buffer. I would hope a basic compositor could be done with not too much code.
Depends, some of us thinks that server side decorations are better for security, because otherwise a client can fake the look of another client.
If the decorations are done server-side then all applications will look the same anyway.
Having said that, I think decorations probably are the job of the desktop environment since those are the things that a user manipulates at that level of abstraction. Moving, resizing, closing programs is a UI thing and an application really shouldn't know where it is within the desktop environment. That's actually a security concern IMHO.
Uh? You should read about QubesOS..
The whole point behind Wayland is to make a 100% clean break from X. Of course as it turns out that means reinventing and replacing all the things that made X good in the first place with something completely new, because newer=gooder. And reading old code is hard, so everything on the Linux tech stack needs to be completely reimplemented so GNOME devs can maintain it for its five-year lifecycle before it all gets thrown out and replaced with something even newer (and gooder).
Writing a heavily constrained, low-level compositor seems like an interesting project. Maybe something that only supports a single type of graphics output, and uses KMS and DRI directly.
Still, there is a convenient Wayland compositor library that is designed for devs to build own window managers. Check wlc . wlc has a nice and simple example  but not as short as TinyWM.
At that point you have recreated a normal efficient way to use a tiling window manager with the additional burden of doing the tiling yourself instead of having the wm do it for you.
It seems likely that those who have an enthusiasm for this workflow are mostly working on desktop environments like gnome/plasma/lxqt.
it's far more useful than a taskbar or expose, since they keep moving what i'm using. the taskbar is a particularly poor design since all i have is a title and at that point i'm just guessing and hoping.
tiling window managers and raise-on-focus systems don't particularly appeal to me because they require me to see the whole of a window. tiling window managers probably have a way to ensure a window is exactly where i left it but it seems antithetical to the alleged advantages. (doesn't "automatically manage your windows" mean "automatically decide where to put a window, and move them around based on the size of other windows"?)
Note that a workspace in this instance is only one monitor in a multi monitor configuration.
By default a single window workspace it takes up all the space. Opening another gives you a new window to the right of the first each half the width of the screen.
On a tall not wide screen it would appear below the first each half the height of the screen.
You can have splitv and splith containers as well as vertical or horizontal tabbed layouts of any kind of windows.
Dialog windows are automatically floating.
You can have containers by containers or nested as you please example 3 horizontal tabs each split in half if you like.
This is a screenshot of my Linux desktop , I use these on OpenBSD as well without too much issue.
How does your setup fare with GL/Vulkan, Chrome?
Found that one out after some digging, seems weird to me that AWT manages to screw this up, to this day, maybe I'll understand what cool trick they do which makes this a problem.
> I use these on OpenBSD as well without too much issue.
Portability is a major benefit of these little window managers, I even ran my dwm fork on Minix3 (on real hardware!), with some minor Make changes  as a bored teenager.
XCB is, per wikipedia, "comparable, but slightly lower-level"; read that with emphasis on "slightly". It's certainly better than xlib, and if you were to write a real WM from scratch these days you should probably use it, but I think bringing it up is sort of besides the point in this conversation: OP was wondering if any sort of cheating was going on by including an X protocol library, and the answer is "no": neither xlib nor XCB would be appreciably providing any sort of abstraction around the concept of "X window manager".
> Move windows interactively with Alt+Button1 drag (left mouse button)
> Resize windows interactively with Alt+Button3 drag (right mouse button)
> Raise windows with Alt+F1 (not high on usability I know, but I needed a keybinding in there somewhere)
> Focus windows with the mouse pointer (X does this on its own)
Well, actually, I would like to see that ... which is to say, I would like to see some GUI apps without borders, etc., since it is something I have never seen before.
And then the first non-comment line is:
Which itself is over 4000 lines and includes tons more code.. It's a pretty meaningless metric.
When someone does a python one liner that just calls a library or something that relies on boost, the point is lost for anyone hoping to have a minimal example.
Hardly. Including standard libraries in the line count wouldn't mean much, unless you're the compiler.
Doing it this way lets you know how many lines are likely to have problems. Not to mention how much code the guy wrote.
The code in X11 libraries is infinitely closer to a window manager than what this guy wrote. This is barely anything at all added to work that other people did already.
The high-assurance community also did a low-complexity GUI:
This "classic troll comment" appears with reasonable frequency in the demoscene: "your 4 kilobyte binary depends on gigabytes of OS libraries" --- and is countered the same way: "as opposed to a multi-gigabyte application also depending on same."
Just as web developers could write x lines of code that run on any web browsers and engines.
A more meaningful objection is that you link with -lX11, which is a significant amount of actual code. But apart from "what about libc and the kernel" counterarguments, the X protocol is actually pretty straightforward - I'd bet you could write this with just socket syscalls in about as many lines of code, too. (Which is to say, an embedded system without libX11 could implement a window manager for a remote machine given just ~100 lines of C or similar and a TCP stack, and the TCP stack is only required because it's remote, anyway.)
X11 is part of the system, just like glibc...
"Here's this lovely new functional language!... written in Haskell, using Haskell's entire runtime as a basis."