Announcement

Collapse
No announcement yet.

Qt 5.1 To Feature Improved Support For Wayland

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

  • Qt 5.1 To Feature Improved Support For Wayland

    Phoronix: Qt 5.1 To Feature Improved Support For Wayland

    A number of improvements to QtWayland have been merged this month, primarily around the Client Side Decorations support and other functionality needed for proper support of this likely X11 Server successor...

    http://www.phoronix.com/vr.php?view=MTI4Njc

  • #2
    Who cares? Qt is still fucking freedom. The CLA is used to circumvent software freedom. Qt is all about commercial licensing. Fuck Qt.

    Comment


    • #3
      Originally posted by funkSTAR View Post
      Who cares? Qt is still fucking freedom. The CLA is used to circumvent software freedom. Qt is all about commercial licensing. Fuck Qt.
      heavens forbid if developers actually try to make money from the fruits of their labor....

      Comment


      • #4
        So Wayland not only enforces inconsistency by requiring that every application draws its title bar itself, Wayland also does not support minimizing of windows.
        I begin to see the benefits of this awesome piece of technology… not!

        Comment


        • #5
          The Wayland backend of GTK also does not support client-side decorations.

          I think you will be able to get client-side decorations by using XWayland though.
          But XWayland is not yet merged in X, but it is planned for the next X.org 7.8 release.

          Once XWayland is merged in, then Wayland will be much more useable through this X compatibility layer.

          Weston still needs to implement window minimizing and a window list.

          I think there are some minor issues with D-Bus that might need to be resolved too.

          Some GTK applications need to get rid of X-specific calls to work natively on Wayland, else they will need XWayland.

          Comment


          • #6
            Remember people Wayland is still somewhat up and coming. (Work in progress)
            Wayland does not enforce inconsistency to make every app draw it's own titlebar.
            The majority of apps uses a toolkit that draws the title bars creating a lot of consistency.

            Would like minimize support in Wayland very much by the way.

            Comment


            • #7
              Originally posted by Awesomeness View Post
              So Wayland not only enforces inconsistency by requiring that every application draws its title bar itself, Wayland also does not support minimizing of windows.
              I begin to see the benefits of this awesome piece of technology… not!
              I don't think the devs are rushing to implement stuff that are needed for a complete desktop but it will happen eventually. Not sure on the timeframe though.

              Comment


              • #8
                Originally posted by funkSTAR View Post
                Who cares?
                Apparently you do.

                Comment


                • #9
                  Originally posted by Awesomeness View Post
                  So Wayland not only enforces inconsistency by requiring that every application draws its title bar itself, Wayland also does not support minimizing of windows.
                  I begin to see the benefits of this awesome piece of technology… not!

                  Relax. The protocol for minimize support hasn't been merged yet, but patches for it do exist, which extends the Wayland protocol, and implants the ability in Weston.
                  Remember what Kristian said about Wayland 1.0. Wayland 1.0 wasn't a release that meant that Wayland is complete for the desktop, but it was a release that meant that the core protocol from that point forward is stable, and the Wayland developers will no longer break existing APIs.

                  Comment


                  • #10
                    Originally posted by nerdopolis View Post
                    Relax. The protocol for minimize support hasn't been merged yet, but patches for it do exist, which extends the Wayland protocol, and implants the ability in Weston.
                    Remember what Kristian said about Wayland 1.0. Wayland 1.0 wasn't a release that meant that Wayland is complete for the desktop, but it was a release that meant that the core protocol from that point forward is stable, and the Wayland developers will no longer break existing APIs.

                    Since you probably follow wayland more than most i have a question. What is still missing for desktop use. There was a post by Pekka sometime ago but i believe things have moved forward since that.

                    Comment


                    • #11
                      Does Google plan to switch Chrome OS to use Wayland instead of Xorg?
                      They could be the main driver to speed up driver development for Wayland.

                      Comment


                      • #12
                        Originally posted by funkSTAR View Post
                        Who cares? Qt is still fucking freedom. The CLA is used to circumvent software freedom. Qt is all about commercial licensing. Fuck Qt.
                        fuck you and your annoying trolling

                        Comment


                        • #13
                          Originally posted by plonoma View Post
                          Wayland does not enforce inconsistency to make every app draw it's own titlebar.
                          The majority of apps uses a toolkit that draws the title bars creating a lot of consistency.
                          Yeah, right. Mixing Qt, GTK, EFL, etc. titlesbars will be so very consistent…

                          Comment


                          • #14
                            Originally posted by funkSTAR View Post
                            Who cares? Qt is still fucking freedom. The CLA is used to circumvent software freedom. Qt is all about commercial licensing. Fuck Qt.
                            Funkstar, seriously, enough of the Qt hate man. Qt is under the LGPL with a CLA, yes. HOWEVER the KDE Free Qt Foundation agreement between Digia and KDE ensures--via a legally binding contract-- that if the LGPL version of Qt were to ever fall behind, the KDE Foundation would receive the latest version of Qt under the BSD license.

                            That right there is the safety net. You can hate on Qt all you want but the reality is its a non-issue because the moment a BSD version of Qt hit the web, "Selling Qt" would no longer be a business model. Its in Digia's best interest to keep the LGPL version of the toolkit updated and continuing.

                            Comment


                            • #15
                              Originally posted by Awesomeness View Post
                              Yeah, right. Mixing Qt, GTK, EFL, etc. titlesbars will be so very consistent…
                              client side decorations are not evil by any means if you actually bother in understand them you will see is a better solution that is X11 today.

                              current X11 limitations:
                              * drawing paths (decoration and widgets) are actually a mess of hardcore API and protocols extension since this was not part of the original X11 protocol
                              * Window title are handle by isolated apps and normally are the compositors too, hence each DE enviroment implemented their own(kwin/metacity/e17/compiz/etc)
                              * title bars and windows are separated X11 objects with lots of hacks included
                              * everything in the screen with X11 is X11 api + extension and since every DE use a different toolkit wich uses this API differently at C/C++level, hence requiring ABI compatibility or bridges to keep visual consistency(almost non existant today)
                              * opengl compositing is alien to X11 core protocol(improved with lots of extension and other subsystems API but still not a first class citizen)
                              * X11 acceleration is at best partial for modern requirements and is very dependant on the driver
                              * X11 is the middle and intermediary of another middle man that knows an intermediary

                              thank to this limitations and the fact that the X11 never included a proper compositor each toolkit had to implement their own, forcing you to use API/ABI compatible visuals normally found only when the same TK is used (Qt/kde apps only look good if you run KDE and Kwin, same for efl/gtk/etc), and ofc since every TK has its own compositor and drawing API you get a salad of visuals if you dont use the correct for every app(GIMP is ugly as hell in KDE and calligra make you wanna puke when you are in Gnome3 shell for example).

                              Wayland pros(some in current development)
                              * in wayland everything is just a TEXTURE, thereis no low level API, no objects, no ABI, no middleman, no extensions, no visuals dependency, no drawing process or server.
                              * wayland is drawing language free, you can draw with G/ASM, Opengl, OES, DirectX(if you had a driver ofc) or any other wicked way you want
                              * wayland is just an assistant that let you talk directly to the a GPU Framebuffer in a coordinated way, nothing else
                              * wayland is a good damn good compositor and it works at framebuffer level inside the GPU automagically(no extensions or API/ABI or server in the middle)
                              * window and windows decorations once again are just textures

                              so with wayland the next predicaments are true
                              * each toolkit could render the app widgets/window & decoration directly with no need for kwin/metacity/etc except for protocol and events handling(so you kde app look like in running in KDE regardless that you are running gnome3)
                              * 1 app could look the same regardless the DE and toolkit(true for widget and decoration) just drawing directly in any form you like(GL GLES DX ASM)
                              * if DE enviroments agree in using a common drawing API that interfaces with Wayland protocol(cairo, GL, etc) to draw widgets/decorations, the DE enviroments just need to implement the skining that can be shared even, so the app looks native regardless the toolkit it was written with and even the themes can be written in a easy lang(js, qml, python, CSS,etc) and loaded by any DE enviroment so your apps looks the same in any DE as long you set same theme or even better 1 theme engine that work in any DE so regardless the TK you used to write your app or the DE you are using all apps will use the selected theme
                              * wayland dont require anything and is not a process, it just a protocol library aka put a kernel load drm modules and get mesa(if you wanna draw in GL/GLES/openVG/etc) and voila
                              * wayland dont impose session API/ABI so kdm/gdm/etc just will be needed for da eye candy cuz the session can be handled using PAM/KRB/AD/etc in the background and you dont need to be root for it
                              * wayland dont handle network rendering, which is very good since is 1500billions times better at TK level and freaking lot more secure than X11 network security blackhole(i know is useful if you use it, so stay with X11 until TK implement theirs)

                              in easiest words wayland behave like libusb or the tcp library, is just an interface that allows you to talk directly to a piece of hardware in a sequence that the piece of hardware can understand but what you sent to the hardware later is entirely up to you in userspace level (like in tcp/IP library doesnt tell you how to torrent just how to package it in tcp/IP format so the hardware can trasmit/receive whatever your libtorrent library generate in userspace effectively), so in wayand everything is client side not just the decorations aka framebuffer background/widgets/windows/decorations/apps/etc all is client side without execption

                              Comment

                              Working...
                              X