Wayland's Weston Compositor Introduces Kiosk/Fullscreen Shell

[Gusar]

You know your stuff oiaohm, that was a fascinating read. You're aware of issues and strengths of both windowing systems, unlike 144Hz's blind "Wayland/Gnome is perfect" fanboyism.

Of course we could see like a case were the wlroot based stuff forks away from the core wayland stuff and we have a fight out between core Wayland and wlroot stuff to see what future winner we have.

Something like that is already the case. Only wlroots developers seem to be interested in creating protocols for things that are missing, with KDE devs generally being on board, but Gnome has no interest in cooperating.

[tildearrow]

Gusar If you disagree with the current Wayland scope and the current Wayland steering group then move on and repeat all the mistakes from the past.

Like "Scripting is a mistake"? Wow, what a terrible ideology you have.

[oiaohm]

Like "Scripting is a mistake"? Wow, what a terrible ideology you have.

https://gitlab.gnome.org/ofourdan/gnome-ponytail-daemon/

The reality is wayland applications are script-able but it requires different way of doing things. Yes remotedesktop api usage instead of XTest. Also using the screencast capture instead of direct screen capture.

XTest in X11 could and up delivering a scripted click to a unattended application its been a documented issue using dogtail to script applications for a long time.

Tildearrow the missing features from wayland like it or not are all broken. Yes windows and OS X script control of applications also have the defect of being able to deliver clicks and key-presses to the wrong application.

Lot of ways even the way that can be done for wayland is not ideal to script applications but it no worse than X11 offered the big difference is the new method you need authorisation to fake inputs or read screen so some random application cannot just do it.

Allowing any random application to be able to read the screen or fake input is a mistake.

This is another case where this stuff is done over dbus not wayland with wayland compositors because this stuff need authorisation.

[tildearrow]

https://gitlab.gnome.org/ofourdan/gn...nytail-daemon/

The reality is wayland applications are script-able but it requires different way of doing things. Yes remotedesktop api usage instead of XTest. Also using the screencast capture instead of direct screen capture.

Bloat

So to script in Wayland compositors I have to train an AI to guess where is the window at?

XTest in X11 could and up delivering a scripted click to a unattended application its been a documented issue using dogtail to script applications for a long time.

Tildearrow the missing features from wayland like it or not are all broken. Yes windows and OS X script control of applications also have the defect of being able to deliver clicks and key-presses to the wrong application.

Oiaohm that is your opinion. At least they have standard ways, while in our case we have to do it per-compositor. Except AT-SPI2

Lot of ways even the way that can be done for wayland is not ideal to script applications but it no worse than X11 offered the big difference is the new method you need authorisation to fake inputs or read screen so some random application cannot just do it.

Yes

Allowing any random application to be able to read the screen or fake input is a mistake.

Allowing any random application to be able to read the screen or fake input with the user's consent is not a mistake however.

This is another case where this stuff is done over dbus not wayland with wayland compositors because this stuff need authorisation.

Yes. Now hope that dbus is fast and lightweight and the compositors implement it.

Come on where is my dbus c++. I have to bring a whole Qt or GTK or tie to systemd for it. Otherwise I get lost in the realm of endless underscores and confusion with libdbus.

[oiaohm]

So to script in Wayland compositors I have to train an AI to guess where is the window at?

https://gitlab.gnome.org/ofourdan/gnome-ponytail-daemon/

[B]Also, Wayland does not expose global coordinates, and ATK will return local coordinates of the various application widgets on Wayland, this is where the RecordWindow method from screencast can be used, as it will translate global coordinates into surface relative coordinates.[/B]

So no you are not using a AI to get where a window is at. Turns out the screencast interface can answer the global coordinates of a window under Wayland.

Oiaohm that is your opinion. At least they have standard ways, while in our case we have to do it per-compositor. Except AT-SPI2

Please note in that line that called the AT-SPI2 interface ATK same thing just gnome implementation. Between the remote desktop interface the screencapture interface and the AT-SPI2 you can recreate something as bad as the old XTest interface. So there are 3 interfaces that quite a few wayland compositors implement that but this is really not the best way as it still broken. Yes you complain this is bloat this is a good thing to be calling bloat since just like XTest it does not work right for script control 100 percent of the time.

Reality is the idea that you have todo this per compositor is wrong.

Allowing any random application to be able to read the screen or fake input with the user's consent is not a mistake however.

Most likely this is a mistake as well. There is a reason why wayland only is giving applications local coordinates instead of global ones that results in ATK/AT-SPI2 information being local coordinates.

Start thinking with wayland you don't really need to fake global input as you have to under X11. Instead faking input to individual applications would be better in most cases. Same with reading screen lot of cases you want to read a window not a screen. Remember multi windows on screen could be on top of the window you are reading screen to attempt to see of the application you are wanting to control.

Yes. Now hope that dbus is fast and lightweight and the compositors implement it.

This is that you have missed something.

https://gitlab.freedesktop.org/mstoeckl/waypipe/

Wayland protocol supports compositor on top of compositor in a never ending stacking. So in theory not all compositors of Wayland have to implement everything. But no one has been coding up proxy compositors to extend features.

Lets say the application you wanted to control you had a proxy compositor between the application and the display compositor. This proxy compositor would not know global coordinates only local coordinates and only need to interface with AT-SPI2 for information. Local coordinates is enough to fake input to applications the wayland design so the proxy can fake input.

This does have some advantages 1 the proxy could intentionally block input to application while mid remote control task. 2 window being moved on screen by display compositor is going to have zero effect on the input going the application. Windows popping over the top are also going to have zero effect on the input going to the application.

The proxy can read the output window no matter what is stacked on top. So now you can remote application by script and go off and do something else without risking disrupting the script controlling the application.

So the proxy wayland compositor route would give you script-able control over an application that 100 percent behaves and allow the application being controlled by script to pushed to background while it does it thing.

Lot of ways I just wish the AT-SPI2 standard would add fake input since we now have local coordinates with wayland and you really don't need to know where the application is on screen to fake input any more.

Come on where is my dbus c++. I have to bring a whole Qt or GTK or tie to systemd for it. Otherwise I get lost in the realm of endless underscores and confusion with libdbus.

Really to use AT-SPI2 to get information to in fact control X11 applications by Xtest you have to interface with dbus anyhow. So this is a universal problem you have to over come not something special wayland causes.

You never considered the idea of a proxy wayland compositor did you to allow you to script control wayland applications. Wayland standard does have a method included to application control in generic way just it means making a proxy compositor and starting application you want to control with proxy compositor. Now if you don't like the proxy compositor route its the screencast and remote-desktop API route over dbus. If you don't like either its then like extend AT-SPI2 to allow input.

I really do think wayland offers up enough options. Just they are different options to the old XTest and Windows and OS X broken methods.

[tildearrow]

tildearrow Enjoy AT-SPI2. Enjoy Pipewire. You know who made it and why they made it.

Stop.

[tildearrow]

The only thing that need to stop is you pretending that 95% of the work on libinput, xwayland, pipewire, at-spi etc is anything but GNOME. Latest example is the new screen casting service. Shell master now depends on pipewire master. Synced development.

It’s fine that KDE piggybacks on GNOME tech but then at least admit it and give credit.

A bunch of excuses. A bunch of freaking excuses.

libinput as an example was authored by somebody working at Red Hat. Yes, I am aware that they were involved in GNOME development, but this does not mean that anything they make is suddenly a GNOME component. Stop.

[tildearrow]

tildearrow How rude of you. Those devs got names. Red Hat pays them to make a GNOME-based desktop.

No, you are worse. Those devs got names, but it does not mean PipeWire and libinput are GNOME technologies.

They are used by GNOME but please, it does not mean it automatically is GNOME tech. It is Red Hat tech.

You just are eager to get GNOME to trample the other desktops and declare world domination.

I can't talk to you anymore. Come on.

[tildearrow]

tildearrow Red Hat sponsors this because it is needed on GNOME@RHEL. Red Hat is not here to help Arch user play around with broken, alternative desktops.

I was going to stop here, but I cannot take this disgrace of you.

Broken. Yeah, broken. BROKEN?!

BROKEN IS WHAT GNOME IS THIS WHOLE FREAKING TIME!!!
ALL YOU WANT IS death to the other desktops, right?! The other usable desktops!

I am tired of you and your horrible propaganda. Seriously. Show me how usable GNOME is.

It is terrible and impossible to use without mass modification. Lots of things that don't make sense. Like a tombstone for "New Tab" or a disk drive (rather than a floppy drive) for Save. Or the dialog buttons in the top rather than the bottom.
And before you say "extensions", sorry but they break on every new release. Do I have to modify the GNOME source code to achieve what you call "True Freedom"?

One more and I am done. Stop, you troll.

[tildearrow]

tildearrow I really can’t answer all your accusations and speculations. I’m just telling you when Red Hat sponsors all the developers it has a purpose. And that purpose is GNOME@RHEL.

OK, let's end the discussion then. Their main focus is GNOME, but that does not mean that auxiliary software is GNOME-branded too.

End of deviation. Let's go back to talking about Weston.