The Ongoing Work For Native Wine Wayland Support

[oiaohm]

So the user wrote that application. It's called a script. Now the user can't "control" his windows. You can't be this dense.

No you are being dense who has not kept up with the changes.

https://github.com/input-leap/input-leap/issues/109

input-leap/barrier/synergy they all require to be able to input events that can move around windows. But these are controls designed that you have a human operator.

Yes using combination of InputCapture xdg-desktop portal and libie from libinput that are both dbus solutions input-leap works.

Now what makes it hard is that you cannot get the position of windows right. Yes screen-capture and process it possible to work out where a window is and send input. Now script is getting insanely complex. What if this is the wrong way.

There is a problem you are forgetting Weasel. User writes script quite a while latter still using script forgets what it does and moves a window at the wrong time causing something unexpected to happen. Issue with X11 and Windows automation. How to avoid this problem.

Lets look at wldbg in the middle between the application and the output compositor. Now this allows a script to control wldbg that then controls the application with relative positions. User moves window nothing bad happens.

More advanced version of this proxy solution the script could lock out user input to application while it does a chain of operations.

For scripting you desktop you really do want wayland proxy compostior that a form of seamless.

Yes feature I want to see is is a proxy wayland compositor made particular for application control. I also would love to see Wayland robustness complete and feature added where you can send message and say please disconnect X application from Y wayland compositor and connect to Z wayland compositor.

Weasel you have not had xnest seamless under X11 that would be what a wayland proxy compositor is.

Relative positioning avoids a stack of problem. Method we have used to automated applications under windows and x11 like it or not has been buggy.

Proxy between application and output source when controlling application is the safest option.

More you look at it giving script absolute positions is more often and not the wrong thing. wldbg and other debugging parts of wayland demo a different way of doing application control. This other way of application control where user and script actions on application can be kept out of conflict with each other.

Yes xnest/xepher getting a seamless option added would give you something like a wayland proxy. Think about it nested/proxy solution you can prevent a script from sending input events to random applications.

Lets try to work to having proper script application control that for sure to send events to the correct application instead of the hacks of application control windows and X11 have had up until this point that have no promise of sending event to right application.

[drastic]

<blah blah blah>
Proxy between application and output source when controlling application is the safest option.
<blah blah blah>
Lets try to work to having proper script application control that for sure to send events to the correct application instead of the hacks of application control windows and X11 have had up until this point that have no promise of sending event to right application.

For as much as I can foresee, I have also concluded that a proxy between the application and a Wayland compositor is the best option, at least if you want to employ my suggested solution with the "executable launcher" permissions file. It can avoid the mess that you mentioned in the quote and allows for the "proper script application control".

[oiaohm]

For as much as I can foresee, I have also concluded that a proxy between the application and a Wayland compositor is the best option, at least if you want to employ my suggested solution with the "executable launcher" permissions file. It can avoid the mess that you mentioned in the quote and allows for the "proper script application control".

Remember there is Wayland robustness as well

https://www.phoronix.com/news/Qt-6.6-QtWayland-Handoffs

Any application that support wayland robustness it is possible to change the wayland compositor the application is connected to without stopping it.

Effect of having interface to-do switching of compositors on demand would be application at worse disappearing for a few frames as you change from normal desktop Wayland compositor to proxy compositor and back.

https://wayland.freedesktop.org/extras.html

Wayland proxy is not a new thing but we don't have one made particularly optimized for applicaiton control using wlgdb todo it is kind of hacking around the hard way but it was good enough for me to proof of concept this control method to myself that it could work..
Wayland robustness is fairly new but its a good thing to have.
Yes possible extra xdg-desktop portal protocol for control of what application is connect to what wayland compositor.

From what I can see this would cover over 95% of the use cases where people want to third party script control applications without needing absolute positioning at all.

Yes the proxy compositor you have options of it having a overlay over the application say in use or something when the automated actions are being done so user in fact can see what in heck is going on.

For the under 5% that don't suite you are most likely wanting to work out the complete wayland compostior and that more inline libie from libinput and desktop capture.

Executable launcher does limit out the cases where you want to run a script todo something on a application you have already started Wayland robustness and extra protocol to handle changing applications from one wayland compositor to another covers those use cases.

I can see application automation being able to be done really well under Wayland. Yes someone just doing up a good wayland proxy for application automation would get a very long way. Taking advantage of Wayland robustness you have something really great.

Yes Wayland open up the possibility for better quality application automation than we have under Windows, Mac OS and X11.

[Weasel]

The user decides, of course.

The permissions for Wayland (including absolute positioning) and other OS permissions should be stored in a file of an "executable launcher" type. The user can create this file by double-clicking on the actual binary, which should cause the OS to run an "executable launcher setup" GUI application., where permissions can be ticked in checkboxes

But it doesn't. Crapland is one of "those" projects with a huge amount of resistance to anything those monkeys don't like, even if it's just an option (not by default).

You are confusing two different use-cases. One is running a normal application, and another is the user running his own scripts.

No, I am not. A script is executed by a "normal application" (the script engine, for example, bash). There is no difference lol.

Of course, a user should be able to grant to a scipt a permission to set absolute window position. However, this is a niche use-case, so I guess that noone is rushing to implement it in Wayland.

It's not niche use case at all for power users. Maybe they need to stop looking at mobile peasants only.

[smitty3268]

It's not about only Wine FFS

That's probably something you need to specify, then, considering you were responding to an article about WINE support.

[drastic]

But it doesn't. Crapland is one of "those" projects with a huge amount of resistance to anything those monkeys don't like, even if it's just an option (not by default).

Perhaps you are right about that, although I'm not absolutely sure.

Anyway, a Wayland proxy should be, mostly, a separate project, so it wouldn't depend much on them.

No, I am not. A script is executed by a "normal application" (the script engine, for example, bash). There is no difference lol.

Of course there is a difference: an application that controls, in real-time, other GUI applications is a special kind of application. Or, at least, a rare kind.

(Edit) Oh, you mean, bash will execute a script. Well, um...
No, when a user executes a script via bash, the script does not automatically get the "absolute positoining" privilege, just like any normal application doesn't get that privilege when you start it directly via file manager.

For a bash script to get the "absolute positoining" privilege, a few conditions must be met:
- bash was started by the user, so bash has "absolute positoining" privilege
- bash then executes "windowContol" command (with window position as an argument), as a part of the script. "windowContol" is a OS-level high-privileged utility; it verifies that it was started by a sufficiently privileged application before moving the specified window to a specified absolute position.

(Of course, this is the real-time case. Setting "initial window position" is different and easier, via an argument to the terminal emulator, the same way as it is currently accomplished, since no special privileges are required in that case).

It's not niche use case at all for power users. Maybe they need to stop looking at mobile peasants only.

Even for power users it is a niche use-case, and power users are a minority. So it is a niche in a minority.

You need a script to set an absolute position of other apps because of what? What's the use-case? The mouse became defunct?

[oiaohm]

No, I am not. A script is executed by a "normal application" (the script engine, for example, bash). There is no difference lol.

You can control wldbg with bash. Unpleasant as hell but can be done. Weasel my prototype to see what could be done was done with bash and wldbg and modified wayland robustness. file handler(for active compositor) to allow wayland robustness to work.

None of this was adding anything to the wayland protocol that is not already there. This was all just implementation details.

Weasel you can send input to a process that bash has run and is running in background to the script. Yes I had redirected wldbg input output and stderr up to 4,5,6 file handles under bash.

This is not the old lets type a command and have something random done. Instead instead it send command to the proxy compositor by file handles.

Like or not there is a completely different way of solving the problem.

[Weasel]

Of course there is a difference: an application that controls, in real-time, other GUI applications is a special kind of application. Or, at least, a rare kind.

Sure, but rarity is irrelevant when it comes to how much use it gets. init daemons (like systemd) are a "rare" kind of app, and yet, it's pretty much one of the essential ones.

(Edit) Oh, you mean, bash will execute a script. Well, um...
No, when a user executes a script via bash, the script does not automatically get the "absolute positoining" privilege, just like any normal application doesn't get that privilege when you start it directly via file manager.

For a bash script to get the "absolute positoining" privilege, a few conditions must be met:
- bash was started by the user, so bash has "absolute positoining" privilege
- bash then executes "windowContol" command (with window position as an argument), as a part of the script. "windowContol" is a OS-level high-privileged utility; it verifies that it was started by a sufficiently privileged application before moving the specified window to a specified absolute position.

(Of course, this is the real-time case. Setting "initial window position" is different and easier, via an argument to the terminal emulator, the same way as it is currently accomplished, since no special privileges are required in that case).

Arcan allows you to control permissions via virtual filesystem, so basic unix permissions, which would work fine.

I'm not looking for ideas how to implement this in Wayland. There's been plenty posted already as MRs. They just won't accept them because they are brain damaged monkeys.

X11 isn't perfect but like I said, I'd rather have functionality than security, as do most people (who are using Windows). You can have both security and functionality, like Arcan, but Crapland does not. And that's by design because they keep ignoring or rejecting such proposals.

Even for power users it is a niche use-case, and power users are a minority. So it is a niche in a minority.

You need a script to set an absolute position of other apps because of what? What's the use-case? The mouse became defunct?

The whole point of automation and scripting is to automate your workflows or whatever. Moving the mouse is a manual task.

You also underestimate how popular AutoHotkey is on Windows. Don't be fooled by its name, it's not just about hotkeys, it's a power user scripting language. You can have zero hotkey scripts that can do all sorts of things, and of course, move windows or query their positions or scan their pixels or whatever (super important for automation).

[drastic]

X11 isn't perfect but like I said, I'd rather have functionality than security, as do most people (who are using Windows). You can have both security and functionality, like Arcan, but Crapland does not. And that's by design because they keep ignoring or rejecting such proposals.

You can have zero hotkey scripts that can do all sorts of things, and of course, move windows or query their positions or scan their pixels or whatever (super important for automation).

Yes, I don't want to prevent that.

The problem is that there is quite a significant difference between granting window positioning privilege to certain applications, and granting it to all applications.

Once the positioning privilege has been granted to all applications, there is no going back, due to compatibility concerns. That's the problem with security regarding absolute positioning.

However, if relative positioning is the default for applications, then absolute positioning can be implemeted at a later time, or granted at a later time.

[oiaohm]

You also underestimate how popular AutoHotkey is on Windows. Don't be fooled by its name, it's not just about hotkeys, it's a power user scripting language. You can have zero hotkey scripts that can do all sorts of things, and of course, move windows or query their positions or scan their pixels or whatever (super important for automation).

https://www.autohotkey.com/boards/viewtopic.php?t=45289

Weasel sorry I know AutoHotkey. I know AutoHotkey users complain about. Notice here person asking for relative position support. Why are they asking for this. Simple the automate an application they forgot its automated move window and all hell breaks less.

Weasel automation is important feature but users of automation don't want the automation to be landmine. They use autohotkey because they don't have good alternative

Yes that scan of pixels results in having todo a hack normally of forcing a window to a particular location on screen even if that happens be on top of where the user happens to be doing something else. Remember as a proxy wayland compositor you don't need to find where on the screen a window is application gave you it window and as long is not encrypted you can read it contents. Screen scraping without having todo lots of maths or risk race condition.

Weasel the autohotkey way of doing automation is filled with race condition problems. We need to go back to the drawing board. Something remember wayland proxy compositor is possible to implement on X11 as well. Man in middle automation does not have the race condition problems.

drastic notice how Weasel here is making his sales pitch with a busted application. This is the problem that happened over and over again with Wayland protocol discussion.