wayland-x11-compat-protocols
wayland-x11-compat-protocols copied to clipboard
probonopd
xdotool replacement using wayland protocols
Not sure I understand your point, can you elaborate? Thanks!
Make A script that mimics xdotools interface but does all of the things using way protocals
Yes. That'd be a good way to do it, but that would require that everything that can be done with xdotools can be done with Wayland protocols. Is that the case?
https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.impl.portal.RemoteDesktop.html Supports absolute mouse movement and keyboard.
https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.impl.portal.RemoteDesktop.html Supports absolute mouse movement and keyboard.
This is not enough for an xdotool equivalent. Window query and modification functions (maximize, close, resize, move, you know) don't exist.
With windows on kde you could make a kwin script
Thanks for the idea, but we need solutions that are not tied to any particular desktop environment.
Good example of KWin script method, kdotool: https://github.com/jinliu/kdotool
Yes, but we need something that works on every Wayland based system, not only KDE.
Yes, I mentioned it cause kdotool seems the best implementation of this type I've seen so far.. (noob here)
There's other guys going the Xwayland rootful way: https://ofourdan.blogspot.com/2023/11/xwayland-rootful-part-2.html
But yeah, in the end this needs to break away from Xwayland and X11 too..
Frankly, their description of how it works makes me wonder what the KWin devs are thinking.
If something can script the installation and running of a temporary KWin Script, what's the point in requiring those APIs to only be used within one? It provides no security benefit.
How the hell is it reasonable to generate a script, load it, run it then delete it for a simple task? What if someone wants to do it every frame? This is just unbelievably inefficient...
Because that's not how the KDE interfaces are meant to be used, just like how you're not supposed to fork a new instance of xdotool every frame.
Sure, they are not meant to be used that way.... but it's not like there are proper APIs to do that sort of thing, either.
My point is that, if you're already writing a KDE-specific tool, the proper solution for attempting to do stuff that quickly is to write a persistent script that just gets installed along with the command-line utility, stays loaded, and waits for commands through some avenue like the creation of a minimized-by-default, skip-taskbar, always-below window containing the relevant control data in its properties.
...plus, this would all make sense as a security measure if they hadn't left the combination to their heavy-duty vault on a post-it note on the door. I can only assume the security model is "Flatpak apps will only have been granted access to the relevant D-Bus APIs in exceptional circumstances and traditionally installed applications aren't part of what's being mitigated against".
Well, kdotool is basically using KWin via DBus as an interface to communicate with the system.. KWin also goes via DBus to interact with the rest of the system/kernel..
This provides a higher level of abstraction making it easier to interact with the kernel, while also adding basic security, although it can be easily bypassed..
I guess if we wanted stronger security we will need to operate on a lower level.
What we need then is something like kdotool that interacts directly with the system/kernel, bypassing in effect KWin.. But that will add a lot of complexity and add its own security risks.. (maybe via wlroots or libwayland?)
Another option could be going through a compositor like Sway, it might bring security of its own, but we'll be limited to its actual capabilities.. (plus not everyone uses Sway)