3 ms·
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
by yjftsjthsd-h 3y ago
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.
- shmerl 3y ago> 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).
- yjftsjthsd-h 3y agoLol - 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.)
- shmerl 3y agoStuck 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".
- t0b1 3y agoMaybe 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. [0]: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2759 https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2759
- jrm4 3y agoThis was the question I came to ask. I've been a Wayland avoider because for me there was nothing "broken" to be fixed. 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?
- shmerl 3y agoYes: https://github.com/ReimuNotMoe/ydotool https://github.com/ReimuNotMoe/ydotool
- yjftsjthsd-h 3y ago>> Occasionally, I've enjoying playing around with window management and hacking with WMs, using stuff like this and/or xdotool and wmctrl. 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.
- shmerl 3y agoFor what xdotool does - pretty much a substitute. For anything else you need a compositor specific tool. KWin scripts or something might work for KDE: https://develop.kde.org/docs/plasma/kwin/ https://develop.kde.org/docs/plasma/kwin/
- yjftsjthsd-h 3y ago> 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.