probonopd / wayland-x11-compat-protocols

The missing Wayland protocols for features that are available in X11 (but are denied by the official Wayland protocols)
117 stars 3 forks source link

xdotool replacement using wayland protocols #13

Open lnee94 opened 10 months ago

lnee94 commented 10 months ago

The remote desktop protocol should be able to do a lot of heavy lifting

probonopd commented 10 months ago

Not sure I understand your point, can you elaborate? Thanks!

lnee94 commented 10 months ago

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

probonopd commented 10 months ago

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?

lnee94 commented 10 months ago

https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.impl.portal.RemoteDesktop.html Supports absolute mouse movement and keyboard.

tildearrow commented 10 months ago

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.

lnee94 commented 10 months ago

With windows on kde you could make a kwin script

probonopd commented 10 months ago

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.

ernzo commented 1 month ago

Good example of KWin script method, kdotool: https://github.com/jinliu/kdotool

probonopd commented 1 month ago

Yes, but we need something that works on every Wayland based system, not only KDE.

ernzo commented 1 month ago

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..

ssokolow commented 1 month ago

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.

Pannoniae commented 1 month ago

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...

ssokolow commented 1 month ago

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.

Pannoniae commented 1 month ago

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.

ssokolow commented 1 month ago

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".

ernzo commented 1 month ago

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)