Announcement

Collapse
No announcement yet.

Wayland-Protocols 1.21 Released With XDG_Activation, Staging Replaces Unstable

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • oiaohm
    replied
    Originally posted by Weasel View Post
    You forgot the quotes around "security".

    Then you have spectre which can find this info out anyway as long as you blindly run apps you don't trust. Now such "security" cripples functionality for literally no gain. Wayland was designed by autists.
    Long term there can be a gain. Ideal world wayland applications would stay running and be able to reconnect to newly restarted wayland compositor. This requires the drivers all done to support this function.

    Security done right also prevents case of multi applications combination errors as well that are possible under X11. Yes this is because window data under X11 is not properly connected to the process that started it so it possible for applications to modify another applications window in ways that result in data going to the program that created the window cause it to fail. These come very hard to debug problems as they are problem only appears when X and Y application are run on the same X11 server at the same time other than that they function perfectly.

    Leave a comment:


  • Weasel
    replied
    Originally posted by tildearrow View Post
    The result of too much security.
    You forgot the quotes around "security".

    Then you have spectre which can find this info out anyway as long as you blindly run apps you don't trust. Now such "security" cripples functionality for literally no gain. Wayland was designed by autists.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by cynic View Post

    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.

    Leave a comment:


  • cynic
    replied
    Originally posted by oiaohm View Post
    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/wayla...13856c7731eb35

    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)

    Leave a comment:


  • elatllat
    replied
    My only wayland want is wayfire to work better,

    Leave a comment:


  • oiaohm
    replied
    Originally posted by cynic View Post
    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.

    Originally posted by cynic View Post
    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/wayla...13856c7731eb35

    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.

    Leave a comment:


  • Charlie68
    replied
    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.

    Leave a comment:


  • acobar
    replied
    Originally posted by oiaohm View Post
    https://invent.kde.org/apol/xdg-acti.../-/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).

    Leave a comment:


  • cynic
    replied
    Originally posted by oiaohm View Post
    https://invent.kde.org/apol/xdg-acti.../-/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

    Leave a comment:


  • oiaohm
    replied
    Originally posted by cynic View Post
    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-acti.../-/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.

    Leave a comment:

Working...
X