Announcement

Collapse
No announcement yet.

Qt 5.0 Beta Released

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

  • #31
    Originally posted by Awesomeness View Post
    Despite being hosted on fdo, Wayland is mostly an Intel project. If Intel orders him to implement something else (or at least an alternative route), it'll happen.
    It's funny... when Kristian worked at Red Hat one of the main criticisms of Wayland was that it was "mostly a Red Hat project" with all the same concerns...

    Isn't the worst case (let's say Intel decides that Word Perfect on DOS had the ultimate UI and should be the foundation for all future Linux work) just that someone else would have to take over the heavy lifting on Wayland ?
    Last edited by bridgman; 09-02-2012, 09:06 AM.

    Comment


    • #32
      Originally posted by RealNC View Post
      You didn't answer the question. If applications can already disable WM decorations, then what's your problem?

      Answer that please, instead of talking around it and trying to sneak out, Mr. Usability Authority.
      Stop spreading lies. You asked “Do you actually know that applications can bypass window manager decorations right now on X?” and I answered “Yes.”
      That's straight and forward and not sneaking out.

      Later in the very same post I wrote: “Once users get GNOME applications into their hand which they cannon minimize under other DEs (Plasma Desktop or whatever) because minimizing is not something that fits into GNOME Shell’s workflow, a shitstorm will break out.”
      You wrote “On Wayland, window decorations will be standardized by your DE. All KDE apps will still look the same. All Gnome apps will look the same.” The part of my post I just quoted points out the exact problem with 'KDE apps have their own window decorations and GNOME apps have their own window decorations.'
      Are you incapable of understanding basic English? Seems that way. Learn English first before replying to any of my posts. It's not my job to explain everything twice for people with lacking English skills.

      Comment


      • #33
        Originally posted by bridgman View Post
        It's funny... when Kristian worked at Red Hat one of the main criticisms of Wayland was that it was "mostly a Red Hat project" with all the same concerns...
        Nothing funny here because I never criticized it for being a Red Hat project just as I don't criticize it being an Intel project.
        Talk to the people who were the 'Red Hat project' critics instead of replying to me.

        Comment


        • #34
          Originally posted by Awesomeness View Post
          Stop spreading lies. You asked “Do you actually know that applications can bypass window manager decorations right now on X?” and I answered “Yes.”
          That's straight and forward and not sneaking out.

          Later in the very same post I wrote: “Once users get GNOME applications into their hand which they cannon minimize under other DEs (Plasma Desktop or whatever) because minimizing is not something that fits into GNOME Shell’s workflow, a shitstorm will break out.”
          You wrote “On Wayland, window decorations will be standardized by your DE. All KDE apps will still look the same. All Gnome apps will look the same.” The part of my post I just quoted points out the exact problem with 'KDE apps have their own window decorations and GNOME apps have their own window decorations.'
          Are you incapable of understanding basic English? Seems that way. Learn English first before replying to any of my posts. It's not my job to explain everything twice for people with lacking English skills.
          And *I'm* supposed to be the troll? Seriously? If you want to see trolling, just read your own posts.

          And talking about English, you didn't even understand the issue. Nor the question. So, let me state it again, so that slower people (like you, apparently) can get it:

          If it's already possible to bypass the WM without Wayland, then what's the problem with Wayland always allowing it?

          If you're really *that* slow and still don't understand the question, then I apologize; I suppose my English skills are really that bad. You see, I learned the language myself. It wasn't taught in school, nor did I have any English lessons. I'm sorry that my English isn't up to your high standards. But I think people with at least half a brain should be able to understand me perfectly.

          Comment


          • #35
            Originally posted by RealNC View Post
            And *I'm* supposed to be the troll? Seriously?
            Yes troll, seriously. And it's not the first time you've been called a troll here on Phoronix. (Just the first time by me.)

            Originally posted by RealNC View Post
            If you want to see trolling, just read your own posts.
            You must be the expert on that topic…

            Originally posted by RealNC View Post
            If it's already possible to bypass the WM without Wayland, then what's the problem with Wayland always allowing it?
            You really don't get it, do you? Wayland is not allowing to bypass the WM for window decorations, Wayland is enforcing it. Under X11 an application has to explicitly override getting the window decoration used by the WM. Under Wayland applications have do it all by themselves. That means that even though one DE’s interface guidelines demand uniformity among them, and I repeat this the third time now, KDE applications will have one window decoration and GNOME applications will have their own and considering GNOME’s currently set work flow, all GNOME applications may not have a 'Minimize' button. Applications not belonging to either group, such as Firefox and Chrome (the latter doing it already by default but with an option to use WM decorations), will have to implement decorations completely on their own.
            Behold the (possible) future of Linux applications: http://imageshack.us/f/145/31341369.png/ (Just an image I gimped up in a hurry.)
            Yeah, after years of working on consistency (such as the fd.o icon naming convention which allows one icon theme to be used by both KDE and GTK applications) the element that was consistent even in the most inconsistent times of Unix GUI applications, the common window decoration by default for all apps is thrown out the window.
            It'll be a usability mess if uphold and all because of some Inkscape users…

            Comment


            • #36
              I will wade in here. One of the features I make great use of is the ability to add custom buttons to the window decoration of every application (in my case the stay on top button). Stay on top is an integral part of my workflow. If we go to having wholesale client side window decorations then I have to convince the maker of every application that I want a little button that lets me pin it to the top - this isn't going to happen and I will loose a valuable feature (well probably I will set a keyboard shortcut for it but I would prefer the button as it also gives a visual indicator). Presumably the toolkit could leave a blank space at the top of it's context window which the compositor/window manager could then composit on the window decorations. This would leave you with a single context, thus eliminating a lot of the problems that Window decorations currently have.

              Comment


              • #37
                Originally posted by Awesomeness View Post
                You really don't get it, do you? Wayland is not allowing to bypass the WM for window decorations, Wayland is enforcing it. Under X11 an application has to explicitly override getting the window decoration used by the WM. Under Wayland applications have do it all by themselves. That means that even though one DE’s interface guidelines demand uniformity among them, and I repeat this the third time now, KDE applications will have one window decoration and GNOME applications will have their own and considering GNOME’s currently set work flow, all GNOME applications may not have a 'Minimize' button. Applications not belonging to either group, such as Firefox and Chrome (the latter doing it already by default but with an option to use WM decorations), will have to implement decorations completely on their own.
                Behold the (possible) future of Linux applications: http://imageshack.us/f/145/31341369.png/ (Just an image I gimped up in a hurry.)
                Yeah, after years of working on consistency (such as the fd.o icon naming convention which allows one icon theme to be used by both KDE and GTK applications) the element that was consistent even in the most inconsistent times of Unix GUI applications, the common window decoration by default for all apps is thrown out the window.
                It'll be a usability mess if uphold and all because of some Inkscape users…
                There's nothing stopping standardization of window decorations by freedesktop.org. I really don't see the issue here. We already have stuff like dbus and libnotify. I can imagine a "libdecor" where the various DEs and/or GUI libraries can hook into. KWin on Wayland (or whatever the part of KDE that will be drawing the decorations will be called) will then work with that.

                I do not think that users will notice much difference, as all that stuff will be handled under the hood.

                Comment


                • #38
                  Originally posted by RealNC View Post
                  There's nothing stopping standardization of window decorations by freedesktop.org. I really don't see the issue here. We already have stuff like dbus and libnotify. I can imagine a "libdecor" where the various DEs and/or GUI libraries can hook into. KWin on Wayland (or whatever the part of KDE that will be drawing the decorations will be called) will then work with that.

                  I do not think that users will notice much difference, as all that stuff will be handled under the hood.
                  So what is the advantage of this over server-side decorations, besides adding more complexity and yet another abstraction layer?

                  Comment


                  • #39
                    Originally posted by TheBlackCat View Post
                    So what is the advantage of this over server-side decorations, besides adding more complexity and yet another abstraction layer?
                    There isn't more complexity. The logic of decoration would simply shift out of the window manager / composer into a library. There is no abstraction taking place.

                    The advantage is that there are no more synchronization issues between the app drawing its buffer, and the wm drawing the decorations.
                    When an app resizes, it is just a matter of rendering into a bigger buffer, and attaching it atomically. No inbetween states where the WM has already drawn
                    bigger decorations, but the app is lagging behind.

                    Comment


                    • #40
                      Originally posted by TheBlackCat View Post
                      So what is the advantage of this over server-side decorations, besides adding more complexity and yet another abstraction layer?
                      There's an abstraction layer already in X11. The WM. In Wayland, there is no WM. So no abstraction is actually added. It will be a replacement for the current abstraction, not a new one.

                      The advantage is that applications have much more control over their decorations. Take Chrome and Firefox as an example; it's not possible in X11 to add tabs and other stylized elements to the title bar. With Wayland, it would be possible to keep the default decoration and add more stuff to it. If the various DEs agree to some common standard (I'm looking at freedesktop.org) of course.

                      Comment


                      • #41
                        Originally posted by Ancurio View Post
                        The advantage is that there are no more synchronization issues between the app drawing its buffer, and the wm drawing the decorations.
                        When an app resizes, it is just a matter of rendering into a bigger buffer, and attaching it atomically. No inbetween states where the WM has already drawn
                        bigger decorations, but the app is lagging behind.
                        That's an advantage that comes at the price of a disadvantage. Currently if an application hangs (not crashed but busy doing stuff) it's still possible to minimize it and do something different until it's done. With CSD that is no longer possible. In the age of demanding JavaScript applications I experienced the need to minimize the web browser more often than to resize windows all the time.
                        Hanging applications can no longer be minimized because in CSD world the application has to agree first. This is also basically the same topic killing applications.

                        That could be worked around by, and here's the reply to RealNC and “his” fdo standardization idea, developing a deamon which handles the decorations which would result in something that basically is a server-side decoration, only on another level. And there is nothing any Wayland dev could do about it. So much you “Wayland works that way and deal with it” shouters…

                        Comment


                        • #42
                          Originally posted by Awesomeness View Post
                          That's an advantage that comes at the price of a disadvantage. Currently if an application hangs (not crashed but busy doing stuff) it's still possible to minimize it and do something different until it's done. With CSD that is no longer possible. In the age of demanding JavaScript applications I experienced the need to minimize the web browser more often than to resize windows all the time.
                          Hanging applications can no longer be minimized because in CSD world the application has to agree first. This is also basically the same topic killing applications.
                          This is taken care of by the task bar. All DEs have one. If you want to kill an app, right click on its task bar entry and select "Close" or "Quit". This could even preempt the common decoration layer (if there's going to be one.) Right now with X11, if the WM hangs, you're screwed because all windows will suffer from that. With client-side decorations, this can't happen.

                          That could be worked around by, and here's the reply to RealNC and “his” fdo standardization idea, developing a deamon which handles the decorations which would result in something that basically is a server-side decoration, only on another level. And there is nothing any Wayland dev could do about it. So much you “Wayland works that way and deal with it” shouters…
                          I don't think that Wayland cares how the client-side implements decorations. A client-side decoration layer wouldn't be a "workaround", it would be intended behavior.

                          Comment


                          • #43
                            Originally posted by Awesomeness View Post
                            That could be worked around by, and here's the reply to RealNC and “his” fdo standardization idea, developing a deamon which handles the decorations which would result in something that basically is a server-side decoration, only on another level. And there is nothing any Wayland dev could do about it. So much you “Wayland works that way and deal with it” shouters…
                            There was never any talk of a daemon. I'm pretty sure what RealNC meant was a library, not a daemon.
                            If developers want to hand decorations to a daemon, so be it. No one can stop devs from building shitty applications.
                            The important part is that there now isn't anything fundamental in the way anymore to implement snappy ones.

                            Comment


                            • #44
                              Originally posted by Ancurio View Post
                              There was never any talk of a daemon. I'm pretty sure what RealNC meant was a library, not a daemon.
                              Yes, he meant a library but a library can't run independent and allow hanging apps to minimize/close.

                              Originally posted by Ancurio View Post
                              No one can stop devs from building shitty applications.
                              The important part is that there now isn't anything fundamental in the way anymore to implement snappy ones.
                              Seems that applications have to be shitty as well to become unsnappy. By your own account only a few applications such as Inkscape are really impaired by that lag.

                              Comment


                              • #45
                                Originally posted by Awesomeness View Post
                                Yes, he meant a library but a library can't run independent and allow hanging apps to minimize/close.
                                There has already been a proposed solution to hanging apps. They can specify a rect denoting the x button,
                                and if there is no reply to a ping, the app will be deemed unresponsive and a terminate dialog might pop up.
                                Also, as someone said earlier, you can always minimize with shortcuts/the panel.

                                Originally posted by Awesomeness View Post
                                Seems that applications have to be shitty as well to become unsnappy. By your own account only a few applications such as Inkscape are really impaired by that lag.
                                It's not a matter of Inkscape being shitty, it just has a lot of UI + vector graphics to draw.
                                The thing about snappiness isn't the only merit Wayland brings. It also flushes out a lot of unnecessary complexity.
                                I'm sure you've read all this here already though

                                Comment

                                Working...
                                X