Announcement

Collapse
No announcement yet.

Qt 5.1 To Feature Improved Support For Wayland

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

  • #16
    Originally posted by 89c51 View Post
    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.
    What's missing really is some shell protocols, or extensions for better desktop integration. (such as minimize, which is not yet merged and I'm sure there might be a few other such protocols that I can't think of right now...)

    Some toolkits don't seem 100% complete, as they don't support features that Wayland has, such as the drag and drop protocol, or the onscreen keyboard protocol. And then there is the issue that QT5 is ported to wayland, so QT4 apps need to be ported to qt5, and many GTK apps have bugs because some of them happen to make X calls directly along with GTK calls when GTK is using the wayland backend causing them to segfault.

    If they are not ported to be Wayland native, then they can use the integrated xwayland server, which currently works, but needs some features, and needs to be integrated to work better with Wayland, so that dnd works, and subwindows such as menus don't appear in random parts of the screen.

    Comment


    • #17
      Who cares? Qt is still fucking freedom.
      Are you using "fucking" as a verb or an adverb here?

      /next (kind-of-on-topic)

      In case anyone is still confused, Weston isn't used by GTK or Qt...ever. Or, rather, it is completely separate from the two tool-kits. In other words, Qt and GTK will implement window decorations, controls, etc., separately from Weston, because they each implement their own Wayland compositors. OTOH, Qt and GTK apps will run under the Weston compositor fine, because the Wayland protocol allows this (compositors running under other compositors). And, I would imagine, in the future (when/if xorg becomes the fallback) Weston will be replaced by "root" compositors similar in design to GDM, KDM, LightDM.

      Weston will still live on, because it is the "reference" compositor.

      Comment


      • #18
        jrch, I read your post like this:

        Wayland pros(some in current development)
        * It doesn't do anything

        so with wayland the next predicaments are true
        * The toolkits will have to do everything that X is doing right now

        Last edited by pingufunkybeat; 01-29-2013, 07:03 PM.

        Comment


        • #19
          Originally posted by Nobu View Post
          In case anyone is still confused, Weston isn't used by GTK or Qt...ever. Or, rather, it is completely separate from the two tool-kits. In other words, Qt and GTK will implement window decorations, controls, etc., separately from Weston, because they each implement their own Wayland compositors.
          That's the thing about client side decorations, the window manager doesn't impelemt them. So altough both KDE (KWin) and Gnome (Mutter) will have their own Wayland compositors it will have nothing to do with the window decorations (altough KWin might implement server side decorations even on Wayland). It's the toolkits themselves that implemet them; so they are the same no mater what compositor you are using.

          Comment


          • #20
            Originally posted by pingufunkybeat View Post
            jrch, I read your post like this:

            Wayland pros(some in current development)
            * It doesn't do anything

            so with wayland the next predicaments are true
            * The toolkits will have to do everything that X is doing right now

            AFAIK toolkits already do everything that X would do many years ago, and usually use hacks to bypass it. Hacks won't be needed with Wayland. And this should be beneficial.

            Also, I'm positive, client side decorations are optional(the compositor can still do them if its decides, or maybe if the program "doesn't want to" and just fall back to some default).

            Comment


            • #21
              Originally posted by pingufunkybeat View Post
              * The toolkits will have to do everything that X is doing right now
              The toolkits are already doing everything X is doing right now, which is exactly why X is so f***ing useless and getting replaced.

              Comment


              • #22
                I think some people here might be misguided in that they think CSD means the toolkits have to draw the decorations.
                The way it will most likely turn out to be is that everyone will use some sort of 'libdeco' to do the drawing instead,
                actually unifying decorations even across compositors, something that wasn't even possible under X.

                Comment


                • #23
                  Originally posted by Ancurio View Post
                  I think some people here might be misguided in that they think CSD means the toolkits have to draw the decorations.
                  The way it will most likely turn out to be is that everyone will use some sort of 'libdeco' to do the drawing instead,
                  actually unifying decorations even across compositors, something that wasn't even possible under X.
                  You know what?

                  That is something I could live with!

                  Comment


                  • #24
                    Originally posted by jrch2k8 View Post
                    1 app could look the same regardless the DE and toolkit(true for widget and decoration) just drawing directly in any form you like
                    So GNOME Shell implemented a usage metaphor that makes minimizing unnecessary. Therefore it's not a completely outlandish assumption that GNOME applications for Wayland will draw a titlebar that won't have a minimize button.
                    Absolutely NO Xfce, Plasma, Unity, etc. would want to use a GNOME application that cannot be minimized. Unity users wouldn't want to use applications with titlebar buttons on the righthand (i.e. the “wrong”) side.

                    Client-side decorations also mean that the application is the only one to decide what happens with a window. So when I load a huge file into an applications and while processing the file the UI becomes unresponsive, I won't even be able to minimize it.

                    Originally posted by jrch2k8 View Post
                    if DE enviroments agree in using a common drawing API that interfaces with Wayland protocol(cairo, GL, etc) to draw widgets/decorations
                    Stupid Wayland takes one of the most useful X11 features away and other projects should fix that? What if they don't? “Too bad, you’re stuck with Wayland now” or what?
                    IMO it's evident that Intel develops Wayland for tablets, smartphones and other devices (smart TVs, IVI,…) that don't have windows and that's fine but then Intel should not act if Wayland was for desktops as well.
                    No one is seriously denying that X accumulated tons of cruft over the decades but attempting to replace it by even throwing X’s good aspects out of the window is absolutely retarded.

                    Comment


                    • #25
                      Originally posted by Awesomeness View Post
                      So GNOME Shell implemented a usage metaphor that makes minimizing unnecessary. Therefore it's not a completely outlandish assumption that GNOME applications for Wayland will draw a titlebar that won't have a minimize button.
                      Absolutely NO Xfce, Plasma, Unity, etc. would want to use a GNOME application that cannot be minimized. Unity users wouldn't want to use applications with titlebar buttons on the righthand (i.e. the “wrong”) side.

                      Client-side decorations also mean that the application is the only one to decide what happens with a window. So when I load a huge file into an applications and while processing the file the UI becomes unresponsive, I won't even be able to minimize it.


                      Stupid Wayland takes one of the most useful X11 features away and other projects should fix that? What if they don't? “Too bad, you’re stuck with Wayland now” or what?
                      IMO it's evident that Intel develops Wayland for tablets, smartphones and other devices (smart TVs, IVI,…) that don't have windows and that's fine but then Intel should not act if Wayland was for desktops as well.
                      No one is seriously denying that X accumulated tons of cruft over the decades but attempting to replace it by even throwing X’s good aspects out of the window is absolutely retarded.
                      "Awesomeness" - please go search for "Unresponsive applications" on the wayland list to see the reasoning behind client side decorations before you go calling the people as well as their ideas/product "stupid"...

                      Comment


                      • #26
                        In other words, if you use an efl application in Unity, it'll integrate poorly. Oh wait, it would anyway.

                        What it really means, is if you use [insert wayland incompatible toolkit here] in Unity, you'll get a rootless X window which is nested inside the wayland compositor, and will have the same decorations as all of your other windows (the compositor which contains the X window, which is part of the toolkit you're using (GTK, Qt, etc.), will use your current theme for that).

                        The only thing which may be off would be the color scheme and the actual application feel (because the wayland incompatible toolkit may not utilize the same theme library). That would be, and is, the case now anyway. Hopefully it will be improved in the future, since color schemes can be relatively simple to represent. It'd be up to the toolkits' developers to decide whether it's worth their time, though.

                        Hopefully, any toolkits which implement the wayland api will also implement this ethereal new theme specification. I've heard it theorized a few times, and I believe it's possible, but I haven't heard any news recently about it. Here's hoping. ^_^

                        Comment


                        • #27
                          Originally posted by Awesomeness View Post
                          Client-side decorations also mean that the application is the only one to decide what happens with a window. So when I load a huge file into an applications and while processing the file the UI becomes unresponsive, I won't even be able to minimize it.
                          Please do some research. This is just plain false.

                          Comment


                          • #28
                            Originally posted by smitty3268 View Post
                            Please do some research. This is just plain false.
                            It would be helpful if you pointed him in the right direction, with a link. How will it work?

                            Comment


                            • #29
                              Originally posted by pingufunkybeat View Post
                              It would be helpful if you pointed him in the right direction, with a link. How will it work?
                              There is a way to tell that applications are not responding (or otherwise something like a busy cursor wouldn't be possible).

                              It's entirely legal (and was proposed on the wayland list) for the compositor (Weston, KWin, etc.) to override the default appearance of the app in that case.

                              That allows the compositor to stick custom menus, or draw it's own titlebar + buttons on top of the hung app, and the compositor is free to force close, minimize, help drag the window, etc. to it's hearts content.

                              I don't have a link, but i'm sure you can google to find it if you want.

                              Comment


                              • #30
                                Originally posted by asdx
                                Qt, not QT.

                                Learn to write please.
                                Learn to write, please. Seems to me he knows how to write just fine--although, he may not necessarily know how the name of a certain toolkit (Qt) is written, or is otherwise lazy.

                                Comment

                                Working...
                                X