Further, it's not even clear that this kind of program is practically possible on Wayland. At best, that's yet another new protocol someone would need to invent that only some compositors would implement.
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?
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/
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.
There is no way to do the equivalent of xdotool type --window 0x600005 "my important input"
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.
Gee, if only there were a modern display server protocol with a fixed security model!
Theoretically, X11 is dangerous. But what isn't?
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).
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