Announcement

Collapse
No announcement yet.

GTK Adds Support For KDE's Server-Side Decorations On Wayland

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

  • GTK Adds Support For KDE's Server-Side Decorations On Wayland

    Phoronix: GTK Adds Support For KDE's Server-Side Decorations On Wayland

    Running GTK3 applications on a KDE Plasma Wayland session will soon look better with GNOME's toolkit now supporting the KDE server-side decorations...

    http://www.phoronix.com/scan.php?pag...DE-SSD-Wayland

  • #2
    So in other words, the situation on Wayland won't be worse than it is on X. Good to know. Still not great, though (I need to use simple-scan for some things and it looks awful).

    Comment


    • #3
      Wine so far dididn't even start working on Wayland support.

      Comment


      • #4
        Originally posted by shmerl View Post
        Wine so far dididn't even start working on Wayland support.
        They say Wayland intentionaly hasn't implemented ( due to security reasons) some options that they need, so it will have to go through xwayland in the near therm.

        Comment


        • #5
          Originally posted by Brane215 View Post

          They say Wayland intentionaly hasn't implemented ( due to security reasons) some options that they need, so it will have to go through xwayland in the near therm.
          Yes, but they didn't think of other approaches so far, or of ways to match / extend Wayland protocols in a way that suits Wine, but fits Wayland security approach. It surely requires some approach change on Wine's side and probably is far from trivial.

          Comment


          • #6
            Originally posted by shmerl View Post

            Yes, but they didn't think of other approaches so far, or of ways to match / extend Wayland protocols in a way that suits Wine, but fits Wayland security approach. It surely requires some approach change on Wine's side and probably is far from trivial.
            https://bugs.winehq.org/show_bug.cgi?id=42284

            I guess same shmerl.

            Reality is Microsoft windows interface has the some of the same defects in design as X11. Extending Wayland protocols to allow what wine need is kind of out as this will fairly much bring back the security problems.

            The best answer is wine virtual desktop on wayland or run under Xwayland. Its not like wine project need to move quickly.

            Why does wine have a virtual desktop mode anyhow. There are some things about windows application behaviours that X11 cannot replicate so have to have a mode that more closely matches windows.

            Also the opengl EGL stuff wayland needs is also need for Android support that is under way and is buggy. Doing Android allows taking on the EGL issue without having to take on the security issue.

            As the first bug answer said wine developers did enough wayland to work out the problem. Has some of the code need for a port to Wayland been done in wine the answer is yes in the work for support for Android. Is there any exact time line for a wayland version of wine currently no. Thinking Android port on-to EGL is not stable enough for product release its way too soon to start wayland implementation.

            Its quite a nightmare change going from GLX/OS X opengl to EGL for wine without having to worry about the enhanced security stuff of wayland as well.

            Its not like there is any particular reason wine project need to rush wayland support as Xwayland will work for quite some time.

            Comment


            • #7
              Originally posted by oiaohm View Post
              Its not like there is any particular reason wine project need to rush wayland support as Xwayland will work for quite some time.
              Yes, I opened that bug to get some feedback. From the comments, it sounds like they investigated it in the past, but stopped further progress because of those blockers. That's what I meant above, that it's not moving now or not being investigated further (approach wise).

              I agree, that virtual desktop can be good enough. For fullscreen applications like games it's altogether transparent. It's more of an aesthetic issue for windowed applications really, since it breaks general desktop integration to a bigger degree.

              Regarding XWayland - sure, it's the only option in the interim, but it's not without its own can of worms. Last time I tried running some games in Wine in the Wayland session in KDE, there were various problems that don't exist in proper X11.
              Last edited by shmerl; 10-26-2017, 11:49 PM.

              Comment


              • #8
                Originally posted by shmerl View Post
                Yes, I opened that bug to get some feedback. From the comments, it sounds like they investigated it in the past, but stopped further progress because of those blockers. That's what I meant above, that it's not moving now or not being investigated further (approach wise).
                Thing you are missing is one of those blocker will be solved by the Android port. Being how to run on EGL.

                Originally posted by shmerl View Post
                Regarding XWayland - sure, it's the only option in the interim, but it's not without its own can of worms. Last time I tried running some games in Wine in the Wayland session in KDE, there were various problems that don't exist in proper X11.
                Wine under android where you are using EGL as you would have to as native Wayland applications makes the can of worm problems of Xwayland look minor.

                Yes they investigated. Yes they found a can of worms very large can of worms. Then it comes can we reduce the size of can of worms we need to deal with at this time and the answer is yes we can just do the port to Android first as that will deal with a percentage of the worms.

                https://github.com/wayland-project/w...nstable-v1.xml

                There is no particular reason to rush. As issues in Xwayland are being fixed. There are features like this inhibit keyboard shortcuts that would allow Wine virtual desktop to function properly once it stable. The reality is lot of the reason why wine goes for high levels of desktop integration under X11 attempt to-do alt-tab in the wine virtual desktop.

                Comment


                • #9
                  Pretty impressed by the size of the patch. Ignoring the protocol file the amount of added/changed lines is quite minimal.

                  Comment


                  • #10
                    Originally posted by bkor View Post
                    Pretty impressed by the size of the patch. Ignoring the protocol file the amount of added/changed lines is quite minimal.
                    Well, all the necessary code should be there because of SSD on X11 anyways.

                    Comment

                    Working...
                    X