Announcement

Collapse
No announcement yet.

KDE/KWin On Wayland To Use Server-Side Decorations

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

  • #41
    To me, SSDs seems like a solution in search of a problem. All the negatives people list about CSDs seem pretty unimportant and easily bypassed to me.

    But then, I don't really care about it much. If KWin wants to try providing SSDs on Wayland, then that's fine with me. We'll see how it works out.

    Comment


    • #42
      Originally posted by smitty3268 View Post
      To me, SSDs seems like a solution in search of a problem. All the negatives people list about CSDs seem pretty unimportant and easily bypassed to me.
      Can you elaborate on that?

      In particular Martin's point about very inconsistent decoration _will_ happen in a CSD system. How would it be easily bypassed without going SSD? The hypothetical libdeco is no solution, we both know every toolkit will have their own solution, as will every app started before toolkits get the functionality.

      Comment


      • #43
        Originally posted by curaga View Post
        Can you elaborate on that?

        In particular Martin's point about very inconsistent decoration _will_ happen in a CSD system. How would it be easily bypassed without going SSD? The hypothetical libdeco is no solution, we both know every toolkit will have their own solution, as will every app started before toolkits get the functionality.
        Inconsistent decoration _will_ happen in a SSD system, too. However, I have no reason to believe kwrite and gnome-terminal will suddenly decide to create their own decorations just because we switched over to CSD. Not only is it stupid, but it also means they will have to (each) write their own controls and hook them into their program themselves. Talk about code duplication.

        No, most programs will continue as they have, and allow the other layers to handle decoration. There will be exceptions, as there are now (__with SSD__), but I believe they will remain the minority.

        Comment


        • #44
          Maybe settle for a "middle-ground" in the end?
          Like, Wayland provides a library to make/render decorations, which also is themable. Even better, it can provide capability to add a button/menu or whatever in the decoration to "increase creativity" for those who want it.(It would need to care for cases like window shading and undecorating windows that have extra stuff in the decoration of course.)
          So the application(actually its toolkit) would use this library to render the decoration in the same texture. But the server/compositor can still "command" the decoration through said library. So shading a window should still be possible, without coding it in the app. You can still have a single texture coming from a window and less IPC. And applications can look consistent(global theming of decoration, just like now). Specifically for the latter,there would be a default theme and the app can still force/request a certain theme, but the compositor optionally can do so as well, and the latter would always come on top in this case(so he compositor would decide if it let's the app choose or not).
          I think it's should be possible, then we should get the best of both worlds. We shouldn't have to only look at two extreme ends, there's always the middle too.

          Comment


          • #45
            Originally posted by Nobu View Post
            Inconsistent decoration _will_ happen in a SSD system, too. However, I have no reason to believe kwrite and gnome-terminal will suddenly decide to create their own decorations just because we switched over to CSD. Not only is it stupid, but it also means they will have to (each) write their own controls and hook them into their program themselves. Talk about code duplication.

            No, most programs will continue as they have, and allow the other layers to handle decoration. There will be exceptions, as there are now (__with SSD__), but I believe they will remain the minority.
            What exceptions there are (Chromium and friends) can still be forced to use the system/wm decorations in a SSD system. Such won't be possible in a CSD system unless I'm mistaken.

            Comment


            • #46
              Originally posted by curaga View Post
              What exceptions there are (Chromium and friends) can still be forced to use the system/wm decorations in a SSD system. Such won't be possible in a CSD system unless I'm mistaken.
              It probably wouldn't be too hard to set it up where IF they have client-side-decorations, they can use them, UNLESS the compositor has a specific setting set to true. Such as Kwin might have "Force consistent window decorations." as a true/false setting. Which would let the apps THINK they had CSD but would override them with SSD if set to true. If false then Kwin would provide decorations unless they had some built in.
              All opinions are my own not those of my employer if you know who they are.

              Comment


              • #47
                Originally posted by Ericg View Post
                It probably wouldn't be too hard to set it up where IF they have client-side-decorations, they can use them, UNLESS the compositor has a specific setting set to true. Such as Kwin might have "Force consistent window decorations." as a true/false setting. Which would let the apps THINK they had CSD but would override them with SSD if set to true. If false then Kwin would provide decorations unless they had some built in.
                it's not (only) a matter of aesthetics or user preference
                as mentioned earlier, for KWin there's also the matter of providing window tabbed grouping, which is something that could be handled client side if windows all belonged to the same application (as the application would know about the windows, their number and their names), but would lose application isolation and complicate the protocol in the case of different applications (because one should know about the others, handle tab group enter/leave notifications, have access to the whole window stack) - so this case needs to be handled in the server / compositor

                so an application running under Kwin could and would use CSD, but SHOULD switch to SSD when tab grouped - thus it would have to support both anyway (for KDE at least)
                otoh, since putting a window in a tab group this is an external action initiated by the wm/compositor, asynchronously for the application, it would be the compositor telling the application to disable (on tab group enter) or reenable (on tab group leave) CSD's, rather than the application requesting them (apart from maybe the initial window creation)

                oh and lets not forget windowed games (especially FPS's..), those hardly have a decoration of their own...

                Comment


                • #48
                  New blog post regarding decorations ..
                  Quick, new article!

                  Comment


                  • #49
                    Originally posted by Rigaldo View Post
                    New blog post regarding decorations ..
                    Quick, new article!

                    Kind of sounds like my idea above-- let the user choose, hybrid approach is gonna be the best option.
                    All opinions are my own not those of my employer if you know who they are.

                    Comment


                    • #50
                      Originally posted by curaga View Post
                      Can you elaborate on that?

                      In particular Martin's point about very inconsistent decoration _will_ happen in a CSD system. How would it be easily bypassed without going SSD? The hypothetical libdeco is no solution, we both know every toolkit will have their own solution, as will every app started before toolkits get the functionality.
                      "Easily bypassed OR unimportant."

                      I don't really care about that. There are already tons of inconsistencies - just try running a GNOME app next to a KDE one and try to count up all the different inconsistencies you can find. Adding the window decorations to that list seems like a pretty unimportant addition to me.

                      And within GTK/Qt apps, i think the toolkit would provide a pretty good job at keeping things consistent. There would obviously be some issues that would pop up, but again - i don't really care.

                      Other people apparently do, so I'm not necessarily against KWin providing SSDs. I just personally don't find it important.
                      Last edited by smitty3268; 10 February 2013, 07:34 PM.

                      Comment

                      Working...
                      X