Announcement

Collapse
No announcement yet.

GNOME Display Settings Now Working On Wayland

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

  • #71
    Originally posted by doom_Oo7 View Post
    Yes but nowadays everybody uses a toolkit like Qt / GTK / FLTK / ..., isn't it ? Apart from some folks in some famous video game company
    I hate the Steam looks so much xD
    Seems Valve use their own proprietary toolkit called VGUI in Steam and all their Source games.

    Comment


    • #72
      Originally posted by Awesomeness View Post
      I watched the Wayland talk from last year's X conference. The “compelling” reason given for CSD was:
      When you rotate a window, you won't get a single jagged pixel line between titlebar and window content.

      But the reality is:
      No one rotates windows and even if one did, nobody would care about a single line of pixels.
      It's not just rotation, the same applies to other transformation effects eg. wobbly windows, scaling and such.

      Thing is, however, the disadvantage of SSD can be overcome by merging the surfaces into one surface before transformation, but this of course requires one extra operation - however, if you have the extra power available to wobble your windows, I don't think it's much of a concern.

      Comment


      • #73
        Originally posted by dee. View Post
        Default to CSD, but if the client wants to use SSD, it can just request the compositor to "draw me a simple decoration".
        So, default to what is used in corner cases. I don't think that's the best idea. Specially because this implies the ones who doesn't care about decorations still need to place code to handle decorations.

        Comment


        • #74
          Originally posted by mrugiero View Post
          So, default to what is used in corner cases. I don't think that's the best idea. Specially because this implies the ones who doesn't care about decorations still need to place code to handle decorations.
          They already need to place code to open windows on the screen. Having to call one extra function with arguments to the effect of "draw me decorations with this title text and these buttons" isn't really anything more than they'd have to do in a SSD-by-default model, either.

          Comment


          • #75
            But isn't this whole discussion academic, anyway? Any Wayland compositor has to support SSD for one simple reason: xwayland. xwayland requires SSD. So any compositor that supports xwayland will need to have SSD support.

            Weston already supports SSD for this reason. It is currently in the xwayland source, which means it is only exposed to xwayland clients, but the code is all there.

            Comment


            • #76
              Originally posted by Awesomeness View Post
              Not the same thing. For example you can't have shortcuts like ctrl+t to open new tabs.

              In my opinion the default should be whatever the application wants, but the user or the window manager should be able to switch to SSD. Otherwise things like unity or plasma active aren't possible.

              Comment


              • #77
                Originally posted by Maxjen View Post
                Not the same thing. For example you can't have shortcuts like ctrl+t to open new tabs.
                You can, there just needs to be an API allowing applications to manage such tabs. I am pretty sure this is planned for kwin, or at least was at one point. In principle there is no reason this should be any more complicated for applications than using a toolkit-provided tab manager. In fact it can even be simpler since they don't need to worry about the location or properties of the tab bar.
                Last edited by TheBlackCat; 08-18-2013, 06:30 PM.

                Comment


                • #78
                  Originally posted by TheBlackCat View Post
                  But isn't this whole discussion academic, anyway? Any Wayland compositor has to support SSD for one simple reason: xwayland. xwayland requires SSD. So any compositor that supports xwayland will need to have SSD support.

                  Weston already supports SSD for this reason. It is currently in the xwayland source, which means it is only exposed to xwayland clients, but the code is all there.
                  No, actually, there is no reason to. XWayland, as a client it is for Wayland, can have its own client side decorations, without the inner X window knowing it; since in X it's SSD, you just disable inner X window's decorations.

                  Originally posted by Maxjen View Post
                  In my opinion the default should be whatever the application wants, but the user or the window manager should be able to switch to SSD. Otherwise things like unity or plasma active aren't possible.
                  I don't know what you call "default", but in my dictionary it's what happens when you don't say anything explicitly, so a default can't be "whatever the application wants". If the application doesn't states what it wants, THEN the default is applied.

                  Originally posted by dee. View Post
                  They already need to place code to open windows on the screen. Having to call one extra function with arguments to the effect of "draw me decorations with this title text and these buttons" isn't really anything more than they'd have to do in a SSD-by-default model, either.
                  Yes. But it's still something not needed, and by basic logic, using custom decorations (the main advantage, IMO, of CSD) you'll need to place extra code, so an extra function call to state you'll use CSD makes more sense there.
                  I think we agree that both should be supported and a sane default should be applied, along with two switches, one for the application to choose what it wants, and one for the user to override application's decisions, and I think that's the most important part. The other point is just a matter of preference, and I don't think it changes greatly the outcome.

                  Comment


                  • #79
                    Originally posted by mrugiero View Post
                    Yes. But it's still something not needed, and by basic logic, using custom decorations (the main advantage, IMO, of CSD) you'll need to place extra code, so an extra function call to state you'll use CSD makes more sense there.
                    Why does it make sense to add an extra function call to CSD-using apps, vs. using an already necessary function call in SSD-using apps?

                    Heck, the function call for CSD and SSD apps could even be the same:

                    create_window(USE_SSD, title_text, button_configuration);
                    vs.
                    create_window(USE_CSD);

                    doable with varargs.

                    I think we agree that both should be supported and a sane default should be applied, along with two switches, one for the application to choose what it wants, and one for the user to override application's decisions, and I think that's the most important part. The other point is just a matter of preference, and I don't think it changes greatly the outcome.
                    If you allow the user to always override the behaviour of apps, then apps will have to code for both CSD and SSD anyway. Which is kind of silly, when you think about it. If the application doesn't have CSD coded in, forcing it to CSD would just create a window sans decorations. If the application doesn't have the SSD codepaths, forcing it to use SSD would create possibly undefined behaviour, or in the best case a window with empty titlebar and buttons that may or may not do anything.

                    Comment


                    • #80
                      Originally posted by Teho View Post
                      Could you list them or point where those are explained?
                      sorry, but no. this argument has raged on for about five years now (hell, it's been going on this forum for about three), and every time people have indulged it and given the right reasons. i'm not going to prolong it, by rehashing exactly the same thing year on year.


                      Originally posted by Awesomeness View Post
                      I watched the Wayland talk from last year's X conference. The “compelling” reason given for CSD was:
                      When you rotate a window, you won't get a single jagged pixel line between titlebar and window content.

                      But the reality is:
                      No one rotates windows and even if one did, nobody would care about a single line of pixels.
                      that's really not even close to either of the main reasons.

                      Comment

                      Working...
                      X