Announcement

Collapse
No announcement yet.

GNOME Display Settings Now Working On Wayland

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

  • #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


            • #81
              Originally posted by daniels View Post
              that's really not even close to either of the main reasons.
              That was the reason given in the talk. I also recall a corner case of something related to Inkscape window resizing stated in the forums once by someone.

              Thing is, you people worked for years only on back-end stuff. You seem to know nothing about usability of user-facing parts (as evident by Weston's crappy usability). If KDE, Gnome, and Ubuntu applications got totally different title bars (in Ubuntu's case even with window buttons on the left side) because they're practically hardcoded because of CSD, it would hurt usability a lot more than stupid jagged pixel lines and those handful of people who resize Inkspace windows all the time.

              At least in GTK and Qt CSD are optional. If you want to live in a usability nightmare, have fun there. I don't and that's why I'll turn CSD off and let KWin5 handle the window borders.
              KWin has a good track record with performance and usability ever since Martin and Thomas took over main KWin development.

              Comment


              • #82
                Originally posted by daniels View Post
                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.
                Forums are pretty much unsearchable... you can't seriously expect people to have read any of the older topics. If you want to explain something once, write a blog post about it. That being said I have read pretty much everything I could find on Wayland during the past four years and I can't remember a single really strong argument for CSD. Then again I don't feel strongly about the subject either so I'm just curious.

                Comment


                • #83
                  Originally posted by dee. View Post
                  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?
                  Because you already need to put extra code related to decorations. You already do care about decorations when you choose to use CSD. The idea is to avoid this boilerplate when you don't. However, I already said it's not a big deal.

                  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.
                  I see. Still, the switch on the functions is a good approach to avoid forcing developers for one or another.

                  Comment


                  • #84
                    Originally posted by mrugiero View Post
                    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.
                    I meant the default from the users perspective. If the user doesn't explicitly tell the application to use SSD the application should be allowed to use either CSD or SSD.

                    The default from the applications perspective can by definition only be SSD. And how SSD is being handled is the responsibility of the compositor. I heard that on plasma active for example SSD is equivalent to no decorations at all and on unity SSD would probably draw no decorations for maximized windows and standard decorations for everything else. On KDE or Gnome it would just be those standard decorations for everything.

                    Originally posted by dee. View Post
                    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.
                    That is not how the switch should work. There should be two cases:
                    1. The application is coded for SSD. => There is no switch
                    2. The application is coded for SSD and CSD. => There is a switch

                    Coding applications only for CSD is bad because
                    - desktops like plasma active or unity aren't possible
                    - consistency freaks can't always have consistent window decorations

                    There will probably still be these kinds of applications (think steam e.g.) but those wont work properly across all desktops.

                    Comment


                    • #85
                      Originally posted by mrugiero View Post
                      Because you already need to put extra code related to decorations. You already do care about decorations when you choose to use CSD. The idea is to avoid this boilerplate when you don't. However, I already said it's not a big deal.
                      But the extra code is probably centered on the toolkit implementing decorations, and does not necessarily knows about what the shell provides for SSD. You cannot include in your app support for SSD you don't know about.

                      So, for seamless porting, it would indeed most likely be the other way: the shell/WM provides an API for windows decorations. If an application does not call this API, then it's a CSD only app.
                      If it does call the API, it a SSD capable app.
                      The API would include calls for the application to say if it is also CSD capable, and to return the WM policy (use SSD or CSD) if both are available.

                      Comment


                      • #86
                        Originally posted by Awesomeness View Post
                        Thing is, you people worked for years only on back-end stuff. You seem to know nothing about usability of user-facing parts (as evident by Weston's crappy usability).
                        weston's not a real desktop environment. it's designed to test proofs of concept, not to be usable on a day-to-day basis with its default desktop shell. but thanks anyway.

                        Originally posted by Awesomeness View Post
                        At least in GTK and Qt CSD are optional. If you want to live in a usability nightmare, have fun there.
                        i don't want to live in a usability nightmare, which is why i don't mix and match random apps from ten different environments all together. the usability nightmare doesn't stop at window decorations: if all your menus, settings, shortcuts, VFS, print, etc is different ... what do window decorations actually buy you?

                        Comment


                        • #87
                          As user of a tiling WM (read: no window decorations at all besides a 1 pixel border) for me the possibility to force applications to use SSD is not an option, it is a must.
                          Simple as that, window decorations have no use at all for me and applications that would display them nonetheless would be not welcome on my systems.

                          Comment


                          • #88
                            Originally posted by daniels View Post
                            i don't want to live in a usability nightmare, which is why i don't mix and match random apps from ten different environments all together. the usability nightmare doesn't stop at window decorations: if all your menus, settings, shortcuts, VFS, print, etc is different ... what do window decorations actually buy you?
                            Your comment totally proves my point: You have no clue about usability.

                            Instead of bringing the current paradigms closer together you basically say: “Fuck mixed environments. I don't mix DigiKam with Gimp and you must neither and I don't care that Gnome does not allow for minimizing windows and Ubuntu's window controls are on the left when every other apps' buttons are on the right.”

                            SSD are the correct way for real-world scenarios. With CSD you can have your usability fuckup. I'm no one who wants to take configuration options away. As long as CSD are optional, I'm fine. I want to use Gimp 3 under PW2 and be able to minimize Gimp like I minimize Dolphin or pin a some window to be always visible or roll it up so only the title bar is visible.
                            No stupid jagged pixel line trumps that!

                            Comment


                            • #89
                              Originally posted by Awesomeness View Post
                              Your comment totally proves my point: You have no clue about usability.
                              right-o.

                              Originally posted by Awesomeness View Post
                              Instead of bringing the current paradigms closer together you basically say: “Fuck mixed environments. I don't mix DigiKam with Gimp and you must neither and I don't care that Gnome does not allow for minimizing windows and Ubuntu's window controls are on the left when every other apps' buttons are on the right.”
                              no, it's just an acceptance that after 20 years of massively incohrent desktops, and seeing them increasingly go their own way rather than even the very basic collaboration previously, things are only going to get worse. so why hopelessly compromise the design?

                              Originally posted by Awesomeness View Post
                              SSD are the correct way for real-world scenarios. With CSD you can have your usability fuckup. I'm no one who wants to take configuration options away. As long as CSD are optional, I'm fine. I want to use Gimp 3 under PW2 and be able to minimize Gimp like I minimize Dolphin or pin a some window to be always visible or roll it up so only the title bar is visible.
                              you're assuming that this actually ends up supported with these clients. good luck with that.

                              Originally posted by Awesomeness View Post
                              No stupid jagged pixel line trumps that!
                              for the millionth time - it's not about the jagged line. i'm done.

                              Comment


                              • #90
                                Originally posted by daniels View Post
                                no, it's just an acceptance that after 20 years of massively incohrent desktops, and seeing them increasingly go their own way rather than even the very basic collaboration previously, things are only going to get worse. so why hopelessly compromise the design?
                                So the solution to "massively incohrent desktops" is to forcibly take away the last remaining bit of coherence?

                                Originally posted by daniels View Post
                                you're assuming that this actually ends up supported with these clients. good luck with that.
                                They don't have to support it. That is the whole point. If the WM can make the decorations, they can implement those sorts of things without the application having to even know about them. But with CSD each application (or at least each toolkit) has to add support for those features independently, drastically limiting what the WM can do.

                                Originally posted by daniels View Post
                                for the millionth time - it's not about the jagged line. i'm done.
                                You still haven't explained what it is about.

                                Comment

                                Working...
                                X