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.
My understanding is that "window managing" tools like this are not possible due to how wayland handles information. Pro: More secure than x11, Con: I can't use wayland. Aside from investing a lot of time learning how to use a tiling wm I dont see how I'm going to get over my addiction to minimizing only the active window. ( xdotool windowminimize $(xdotool getactivewindow) )
For improved security with X11, try firejail+Xpra, or Qubes OS. They will not just help in the graphical front, but also others like processes and storage isolation.
Besides the limitations others have mentioned users should be aware that since ydotool works by writing events directly into /dev/uinput the input will go to whatever happens to be focused at the moment. It will happily type your secrets into a chat window if you move the mouse at the wrong time.
There is no way to do the equivalent of xdotool type --window 0x600005 "my important input"
It's not like xdotool is so secure in the first place. X11 is one huge hole from that perspective. Anything can read anything and all your important input can be read by some other window anyway.
This is a totally different issue; Wayland gives up the ability to provide user-aid that prevents an obvious human error. This is not really a security issue, it is a usability issue that can just happen to allow a user to make a security slip-up.
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.
> For what xdotool does - pretty much a substitute.
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.
Makes perfect sense for it to be something that interacts with the compositor. So KWin does expose such API. But that's not part of Wayland itself or its protocols.
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.
> Further, it's not even clear that this kind of program is practically possible on Wayland.
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).
Lol - it's "stuck up" to prefer software that works? If you want people to switch, it'd help to actually cover their use cases. Showing up to proclaim software "obsolete" when the supposed replacement literally doesn't support the features in use, then... what, claiming we're bad people for not contributing to Wayland? is the cultural part of why people don't like Wayland. (In a distant second place behind the technical reasons people don't like it, which boils down to missing features and present bugs.)
Stuck up means they don't care to collaborate. If they don't, how would anyone know about their specific needs? Those who don't have this dinosaur mentality do work with Wayland developers and their needs are addressed faster. Others learn the hard way but also usually like to complain that "things don't work".
Maybe people don‘t because they see, for example, Valve (a billion dollar company) struggling to get GNOME to implement drm-leasing for VR headsets. IIRC they‘ve been at it for multiple years, too.
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.
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?