Wayland-Protocols 1.21 Released With XDG_Activation, Staging Replaces Unstable

[loganj]

"XDG_Activation has been in the works since last year and already has pending support for Qt Wayland, KWayland/KWin, GNOME's GTK and Mutter, WLROOTS, and more."
i thought that wayland is a independent protocol. not something specifically design for qt/gtk/whatever
shouldn't be the other way around? qt/gtk to implement support for xdg?

[oiaohm]

Maybe GTK modals are centered because of the center modal windows option in GNOME, or the fact it knows a parent window and Firefox does not set it...

Turns out if you put particular versions of Firefox main window under X11 at top conner position 0.0 the placement maths go stupid. Firefox was basically giving the Wayland compositor a total bull crap offest to its main window all the time because it was acting like it had 0.0 placement.

Some bugs wayland brings out in applications do infect the X11 version just normally with the X11 version not in the right place on screen to trigger it.

This was a true garbage in=garbage out on the wayland server side. If firefox is going to provide garbage directions and the wayland compositor follows those directions placement is going to be garbage. Yes X11 with those versions of firefox with right/wrong screen placement is going todo the same disaster.

Now windows can't even suggest where to be placed, while this very basic thing was on X11 for ages.

There have been ways to suggest placement for ages with Wayland. It really simple to forgot applications at times even with X11 screw up their maths and give garbage directions resulting in wacky wrong window placement at best and at worse crash to likes of a divide by zero error taking all your data with it. Yes wayland and xwayland is bring some of these errors out and clearly displayed.

PS is really simple to miss but when you are using absolute placement instead of Wayland relative placement there are more to check for when calculating window placement that you don't have hidden error that only going to trigger if your window is at a particular location/s so creating these problem in those cases. There are a lot of bugs that have randomly hit people over years that have been hard to replicate that will not be there with after the change to relative placement. Of course there is going to be a few teething problems as a few of these hidden bugs get dug out by the change over.

[oiaohm]

can someone please explain what does this mean?:

"This protocol is for transferring focus between top-level surfaces such as from a launcher to launchee."

is it a different flow than when I launch something in gnome by clicking on its icon in the overview (or how is it called) or if I lunch a graphical application from a terminal? They already transfer the focus on the new application window.

https://invent.kde.org/apol/xdg-activation-test/-/tree/master

That such as is more of a reference to the sample where is a graphical application launching another graphical application while still maintaining focus on the launcher.

This does provide the framework to change focus between applications does not have to be just launcher to launchee.

Depending on how this develops this could be useful for those who want to automate wayland desktop.

[cynic]

https://invent.kde.org/apol/xdg-activation-test/-/tree/master

That such as is more of a reference to the sample where is a graphical application launching another graphical application while still maintaining focus on the launcher.

This does provide the framework to change focus between applications does not have to be just launcher to launchee.

Depending on how this develops this could be useful for those who want to automate wayland desktop.

got it, thanks!
so with this protocol the launchee could give the focus back to the launcher, for example?

there should be any kind of relationship between those windows?
you mentioned automating the desktop, wouldn't it be a security issue if I can move the focus on other external windows? (or, if an automation tool can steal the focus)?

I'm pretty sure the wayland team have though about it, but I'm just curious on how this is managed

[acobar]

https://invent.kde.org/apol/xdg-activation-test/-/tree/master

Depending on how this develops this could be useful for those who want to automate wayland desktop.

I hope you are right about this, xdotool is part of the tools I use almost daily and ydotool is not fulfilling my needs yet (that, by the way, is way less than what xdotool provides).

[Charlie68]

I don't know if this is related, but it should also finally allow the task manager to report the application starting via animation. This is still missing and when I asked the dev. KDE, they told me it had to be implemented on the Wayland side.

[oiaohm]

so with this protocol the launchee could give the focus back to the launcher, for example?

With the wayland implementation this is yes. As long as the launchee has the launchers activation token and it still valid.

there should be any kind of relationship between those windows?
you mentioned automating the desktop, wouldn't it be a security issue if I can move the focus on other external windows? (or, if an automation tool can steal the focus)?

I'm pretty sure the wayland team have though about it, but I'm just curious on how this is managed

The thing here is a token has to be issued to use activation.

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/50/diffs#diff-content-7b1a427b51eea37983e26cee3b13856c7731eb35

The X11 text with this for emulation of the old DESKTOP_STARTUP_ID notification stuff clearly states that is perfectly fine and applications should expect that a wayland compositor may simple say no I am not giving you focus even that you requested it.

Do note I said activation token had to be still valid. With this new protocol application can give a activation token out then invalidate it. Old X11 you could not invalidate activation of a window token.

This documentation method has how for a application to generate its own activation token and use that with wayland compostior. Does not cover how to get other windows activation tokens or the like.

"Depending on how this develops this could be useful for those who want to automate wayland desktop."

This depending how it develops is there is useful possibility here but with automation in a lot of cases you would want to talk to the compositor and be able to get a list of all windows you are interested in activation tokens this would be a different item most likely something under the AT-SPI2 dbus stuff.

[elatllat]

My only wayland want is wayfire to work better,

[cynic]

With the wayland implementation this is yes. As long as the launchee has the launchers activation token and it still valid.



The thing here is a token has to be issued to use activation.

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/50/diffs#diff-content-7b1a427b51eea37983e26cee3b13856c7731eb35

The X11 text with this for emulation of the old DESKTOP_STARTUP_ID notification stuff clearly states that is perfectly fine and applications should expect that a wayland compositor may simple say no I am not giving you focus even that you requested it.

Do note I said activation token had to be still valid. With this new protocol application can give a activation token out then invalidate it. Old X11 you could not invalidate activation of a window token.

This documentation method has how for a application to generate its own activation token and use that with wayland compostior. Does not cover how to get other windows activation tokens or the like.

"Depending on how this develops this could be useful for those who want to automate wayland desktop."

This depending how it develops is there is useful possibility here but with automation in a lot of cases you would want to talk to the compositor and be able to get a list of all windows you are interested in activation tokens this would be a different item most likely something under the AT-SPI2 dbus stuff.

Thank you for the long explanation: very interesting and informative!

I used to use the X11 protocol some 25 years ago and things were very simpler back then (or, the things I needed to do were simpler)

[oiaohm]

Thank you for the long explanation: very interesting and informative!

I used to use the X11 protocol some 25 years ago and things were very simpler back then (or, the things I needed to do were simpler)

X11 protocol has changed a lot over 25 years. Like 25 years ago the DESKTOP_STARTUP_ID notification feature in X11 did not exist either. That about a 21 year old feature as in a feature from 1999/2000.