Window selection allows for multiple criteria at once, and I can also reject windows.
I'm also able to use the window manager's client list as a source, which makes getting toplevel windows much easier.
Window movement is done using static gravity, fixing an issue where windows were moving differently if they were a terminal window versus non-terminal window.
Bonk can delete properties. I sometimes delete WM_NORMAL_HINTS if a window has size hints set where I can't resize it the way I want.
xdotool can raise windows but can't lower them (bonk can do both).
With kwin it's easy to manually override an application/window to ignore geometry constraints or whatever. I do this for xterm to avoid having a few pixels of background showing at the edge when maximized.
I also used to do this a lot to get the much-nicer "soft fullscreen" in SDL1 applications.
I updated my script for i3wm to toggle windows between scratchpad/active/start/stop:
https://gist.github.com/tkapias/0443d4930c1d7b520f4496e1ff39...
Obviously.
X11 is absolutely not the way to go.
Come to think of it, I should put in better documentation for the state option, as well as a general maximize alias.
I'm not talking about low-level system/graphics bugs, but standard shell/toolkit/application bugs. Things like "alt-letter does not select the correct menu" and "switching between English/Greek keyboard layouts sometimes gets stuck".
Sometimes adding a compositor like Compton helps, but you still see it
When Wayland will get better and apps start supporting Wayland more than they support X11, it will be the time to switch, but at the glacial pace Wayland advances, chances are that your current system will be obsolete when it will happen.
It is still a good idea to consider Wayland support for your own apps and have at least a test machine running it, but doesn't mean writing apps designed to work with X11 like this one is a wasted effort. X11 is here to stay, for a while at least.
Occasionally, I've enjoying playing around with window management and hacking with WMs, using stuff like this and/or xdotool and wmctrl.
I was curious as to what this might be like in Wayland-land? Do tools like this even exist?
It's pretty clear. But some are too stuck up to even research it or be part of shaping it. Which is common among legacy vendors who very rarely even care to communicate with Wayland developers about their needs.
Those who aren't stuck up deal with it just fine (OBS Studio for example).
If you run more than one monitor with different DPI, Wayland is the only choice. If you want to do HDR, Wayland will be the only choice.
> When Wayland will get better and apps start supporting Wayland more than they support X11, it will be the time to switch, but at the glacial pace Wayland advances, chances are that your current system will be obsolete when it will happen.
Toolkit developers are already considering removing their X11 code paths. All of the effort is going into Wayland. The best time to switch was a few years ago. The second best time to switch is now.
For me it's definitely not usable yet, let alone the "only choice"
> All of the effort is going into Wayland
Yes, because it's still work in progress. And at some point in the future that effort will have paid off, but that's not now and definitely not a few years ago.
I run multiple monitors with differing physical DPIs on X11. Yeah, that means they have differing resolutions. It doesn’t bother me, and I can do all the things that I want, unlike if I were using Wayland.
Maybe someday Wayland will be a replacement for X11, but that day is not today.
I'd say within this year already. Some major parts like explicit sync are being merged already. And all future work (like HDR) will only go to Wayland. Not to X11.
So this claim that X11 is a viable option is a fallacy.
It's my computer. I decide what's "the way to go" or "viable" there. None of your business. No one is forcing you or anyone to use it.
This is clearly a "I wrote it because it's useful for me, I put it online for whom it may concern"-type of project. You need to calm your tits and stop shitting all over people's hobby projects.
There isn't anyone left standing to care for X11 development, only vocal users.
Or maybe it‘s because the compositor developers are not exactly concerned about ease of development. To quote a GNOME dev[0] about support for the aforementioned drm-leasing protocol:
> I honestly don't have a problem with forcing clients to implement the portal if they want to work on mutter.
I wouldn‘t blame the people who choose to simply not engage with that process, especially those who work on these things in their free time.
[0]: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2759
And because the X11 maintainers decided that Wayland is the way forward and X11 will simply not get new display features like HDR.
Is Wayland a racket? Barely maintain the previous code instead of making clear that others should take it over because you are insterested in something else, then force everyone into your new incomplete code base, and probably bill for the reimplementation of basic capabilities, piece by piece.
OTOH, not everyone involved with X11 thinks it has no future. Keith Packard posted ideas [0] about how to improve it further.
Anybody who wants to maintain Xorg is free to step up.
Nobody has really stepped up.
Gee, if only there were a modern display server protocol with a fixed security model!
There is no way to do the equivalent of xdotool type --window 0x600005 "my important input"
Ydotool readme:
> Currently implemented command(s):
> type - Type a string
> key - Press keys
> mousemove - Move mouse pointer to absolute position
> click - Click on mouse buttons
So... No.
KWin scripts or something might work for KDE: https://develop.kde.org/docs/plasma/kwin/
Theoretically, X11 is dangerous. But what isn't?
In exchange, Wayland gains… well, nothing really, the idea is that it’ll protect users from malicious programs peeking at other windows on their computer. But in that case situation is already FUBAR, there’s no way to protect a computer that is already running attacks locally on itself.
No; for just the input functions, and that only if you're not using `--window`, it's a substitute. But xdotool is a lot more than that.
> For anything else you need a compositor specific tool.
Yes, exactly. For the things that were asked for, your best hope is do see if your particular compositor deigned to provide the API surface, and then if it did, write something that uses those non-portable APIs to do what you want.
Want to make it easy? Use KDE which cares about flexibility and write scripts for it. Otherwise - probably tough luck, not sure how much other compositors even care about such things.