Announcement

Collapse
No announcement yet.

Wayland Becomes A FreeDesktop.org Project

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

  • #16
    Wayland doesn't use something called "window manager". With X11, apps only draw contents of windows, and frame + title bar is drawn by window manager. With Wayland, like e.g. MS Windows, apps draw not only contents, but also the title bar, etc. This is why screenshots of gtk+/qt on Wayland show windows without title bar (it's simply not drawn at all by these toolkits on X11).

    But about *compositing* managers... I'm not that much into Wayland

    Comment


    • #17
      Originally posted by Elv13 View Post
      It is possible, KWin have been ported to Windows (I don't know if it still work or if the work have even been merged). I don't know that much about Wayland, but KWin is not that dependent on X11.
      I wonder where you got that from (maybe this aprils fools joke?).
      KWin is a X window manager with optional compositing support, nothing else. Thus it heavily depends on X technology.

      Qt has its own form of window management built in, which wayland is being ported to.

      Some details about it here. I wonder how this will work/look in the end...

      Comment


      • #18
        Originally posted by 89c51 View Post
        can somebody explain the situation with the window managers compositors etc on Wayland??

        things like Kwin Metacity/Mutter Enlightenment Compiz just have to slightly modify the code to target wayland right??
        nope.

        see my above post. I don't know exactly, but I guess that the same is true for other X window managers as well. They all implement something that is very specific to X and it wouldn't make any sense to "port" them (read http://en.wikipedia.org/wiki/X_window_manager for example).

        Comment


        • #19
          What are the benifits of apps drawing their own borders compared to sync fences?

          Comment


          • #20
            Originally posted by V!NCENT View Post
            What are the benifits of apps drawing their own borders compared to sync fences?
            The apps can have application-specific borders, like Chromium has. You could also do a lot of other creative stuff like merging and dividing windows, or making shaped, round/octogonal/etc windows, not only rectangular. Imagine a music player which has a playlist part, an equalizer part and a main control part. They are oval, but if you put them close together, they merge (using a pretty animation) to become one in whatever order and at whatever side you like.

            The current X window manager paradigm doesn't offer the flexibility to do a lot of stuff. Look, for example, at Audacious. it can do some of the above, through native X features and assorted hacks, but it has some limitations. If you attach component windows together, you can still drag the whole composition around only by dragging the main window. You cannot merge them together so that it is essentially one window; it is visually obvious that it is several different windows stuck together. Also, dragging it around can produce visual glitches; for example, if you drag the Audacious window near a panel, it will try to stick to it, but the sticking effect only works with the main window, the rest seems to be dragged individually, unsticking them from the main window.

            Just several thoughts.

            Comment


            • #21
              There are many more Disadvantages of having the apps draw their own borders

              http://blog.martin-graesslin.com/blo...w-decorations/


              Have you ever opened up a maximized window in Windows, and then have it open up a progress window for a long operation, and then try to minimize or move the maximized window, only to have it throw a "ding" sound at you, and flash the titlebar of the progress window?

              Comment


              • #22
                Originally posted by nerdopolis View Post
                There are many more Disadvantages of having the apps draw their own borders

                http://blog.martin-graesslin.com/blo...w-decorations/


                Have you ever opened up a maximized window in Windows, and then have it open up a progress window for a long operation, and then try to minimize or move the maximized window, only to have it throw a "ding" sound at you, and flash the titlebar of the progress window?
                There are several good arguments in the article, but the blogger is seriously exaggerating the problems. For example, non-consistency is already possible and an issue, as exemplified by Chromium. Whether client-side window decorations are implemented or not, it is already possible to use something application-specific. CSWD just makes it easier to make a good application-specific windows decoration, which you can't convince me is bad. I'm sure there will be a common window manager library; maybe there will be two, one for GTK and one for Qt, if the two don't agree on something. But GTK and Qt visual incompatibility is nothing new, and I don't see how common window decorations with different widget styles is any better than different windows decorations with different widget styles. There will be something like QtCurve, but for windows decorations, for those who want consistency.

                Also, I can't see why CSWD can't be handled by an external windows decorator like Kwin or Mutter. I'm sure current X window managers can be altered to be usable by non-X programs, if there is a common API for using a window decorator. It's only apps which specifically want to render their own decorations which will have any of the problems described. So I don't think using client-side windows decorations will have any disadvantages; it will only offer more possibilities.

                All of this depends on the way things are handled by GTK and Qt developers. I'm sure it's possible to make a mess of things; however, with some planning and collaboration between the two factions, a lot can be gained at minimal cost.

                Comment


                • #23
                  Drawing their own window was understood by me like technically drawing their own window plus border and not like having UI circus like on MS Windows. I hate that.

                  Comment


                  • #24
                    Still not impressed by Wayland. Even less so now that I realize that apps draw their own titlebars, etc. on it.

                    Comment


                    • #25
                      Originally posted by KellyClowers View Post
                      Still not impressed by Wayland. Even less so now that I realize that apps draw their own titlebars, etc. on it.
                      really?

                      Like how in X apps draw the title bar?

                      How the weird do you think things work in X?

                      Comment


                      • #26
                        Originally posted by V!NCENT View Post
                        Drawing their own window was understood by me like technically drawing their own window plus border and not like having UI circus like on MS Windows. I hate that.
                        Uh. they can do that in X if they want. Anyways your window manager is a X application and it draws the borders for everything.

                        I don't understand how people came to the bizzare conclusion that this is something new or undesirable.

                        Comment


                        • #27
                          Having window management in a separate process is a FEATURE, and not a bug.

                          It's the best thing about X, period. I hate unminimiseable and uncloseable zombie windows on that other operating system.

                          Window management the X way comes at a cost, which is evident in issues such as rubber-banding when resizing, etc. But it's still very useful.

                          Comment


                          • #28
                            Originally posted by pingufunkybeat View Post
                            I hate unminimiseable and uncloseable zombie windows on that other operating system.
                            Oh, and having the whole UI freeze because of io activity is better? A non-responsive window which can be dealt with by killing the application that is responsible for it is the least of Linux's problems when it comes to dealing with hung apps.

                            I think Wayland can pull off an emergency process killer which would work under any conditions, even with peaked CPU and IO activity. Window managers are not an answer to the problem of unresponsive hung apps.

                            Comment


                            • #29
                              loonyphoenix This is not just about hung apps, but this is also about apps that have unminimizable/unmovable windows just because of a modal window open.

                              And killing an app with an unresponsive GUI is not a good idea, it could still be working, but too busy to update its GUI (because its single threaded).

                              Window managers may not be the solution to hung apps, but that does not give them the excuse to create problems related to hung apps.

                              Comment


                              • #30
                                Originally posted by nerdopolis View Post
                                loonyphoenix This is not just about hung apps, but this is also about apps that have unminimizable/unmovable windows just because of a modal window open.

                                And killing an app with an unresponsive GUI is not a good idea, it could still be working, but too busy to update its GUI (because its single threaded).

                                Window managers may not be the solution to hung apps, but that does not give them the excuse to create problems related to hung apps.
                                I still don't think that would be a problem with Wayland. You might be right about all clients drawing decorations themselves, and windows managers might be very useful, but I think window managers can still be implemented in a Wayland environment. Why can't a separate window manager be just another Wayland client which draws decorations around the areas that all other clients request? That seems like the natural way a transition between X and Wayland might evolve. X apps will have fewer things to rewrite if the API of Wayland window managers stays compatible. The development of Wayland is pretty young, and I think the developers will come up with a working solution.

                                Comment

                                Working...
                                X