Announcement

Collapse
No announcement yet.

KDE Now Deals With GTK CSD Headerbars - Improving GNOME App Integration On Plasma

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

  • #31
    Originally posted by Gusar View Post
    Yeah, the argument is that applications shouldn't need to link to GTK just to get decorations. mpv is a low-level application, a GTK dependency would be overkill (mpv works without any windowing system, it can optionally use GBM/DRM to draw directly to the screen and that's with opengl rendering and hardware video decoding). Especially when it wouldn't be necessary if the Gnome devs implemented xdg-decoration.
    There is a library someones working on that's a way of applications to get basic decorations (called libdecoration) without having to rely on GTK under GNOME. I'm not sure how far it's got, but that might be the way forward.

    Comment


    • #32
      Originally posted by Britoid View Post
      The idea GTK follows is similar to the former model, if you want a window on the desktop, you create a GtkWindow and draw to it and the underlying GTK apis handle the decoration for you. This is maybe a contentious issue.
      Yeah, because, if the GTK+ people aren't willing to implement xdg-decoration, then they should accept Qt as "the platform's native toolkit" and link against it. Problem solved.

      (What? It's just as arrogant and ridiculous as the GTK+ devs acting like children and expecting to push their toolkit on everyone else when it's hard enough getting game developers to just test their SDL-based ports properly in the face of things like multi-monitor desktops.)

      Comment


      • #33
        Originally posted by 144Hz View Post
        tildearrow We discuss CSD because the news topic is CSD.
        You are so annoying!
        The news topic is about KDE's weekly report!!!

        Comment


        • #34
          Originally posted by ssokolow View Post

          Yeah, because, if the GTK+ people aren't willing to implement xdg-decoration, then they should accept Qt as "the platform's native toolkit" and link against it. Problem solved.

          (What? It's just as arrogant and ridiculous as the GTK+ devs acting like children and expecting to push their toolkit on everyone else when it's hard enough getting game developers to just test their SDL-based ports properly in the face of things like multi-monitor desktops.)
          Same applie to Qt developers. Let focus on proper communication please regardless the fanaticism.

          Comment


          • #35
            Originally posted by finalzone View Post

            Same applie to Qt developers. Let focus on proper communication please regardless the fanaticism.
            I'm not at all a fanatic. I'm saying that it's ludicrous and juvenile for any set of toolkit developers to unilaterally declare that the only acceptable solution is for others to either add their toolkit as a dependency or reinvent part of it. (The latter of which will still produce an inferior result unless their theming system is also reinvented.)

            Comment


            • #36
              Originally posted by bug77 View Post
              The point is not whether KDE supports CSD or not. The point is the whole GTK+ camp think everybody should support only CSD (because that's what they do) and somehow still enforce consistency. You can't win that argument, you can't put it to rest.
              It doesn't matter what their design vision is; we now support it. They can't force us to use CSDs for our apps any more than we can force them to abandon them. Yes, this leads to some inconsistency in that some apps use SSDs and some use CSDs. That's the price of window decoration diversity. Given that we can't unify everything, our next best choice is to try to integrate CSDs well enough that the differences don't regress usability any further and aren't visually jarring.

              Comment


              • #37
                Originally posted by aufkrawall View Post
                I once opened this and closed it in anger:
                https://bugs.kde.org/show_bug.cgi?id=397850
                I'm afraid that wasn't very helpful. Closing a bug because it hasn't gotten fixed yet is probably the opposite of an effective approach. At the minimum, if you know your bug is a duplicate of another bug, please mark it as such. This *is* helpful because bugs with a lot of duplicates attract a lot of attention, and increases the chance that I or someone else will notice them, which raises the possibility that they'll eventually be fixed.

                Comment


                • #38
                  Originally posted by bug77 View Post

                  The point is the whole GTK+ camp think everybody should support only CSD (because that's what they do) and somehow still enforce consistency. You can't win that argument, you can't put it to rest.
                  CSD is optional in GTK. Nobody forces developer to use GtkHeaderBar it's not only optional but also not default. How "GTK+ camp" forces CSD if CSD is entirely optional feature?

                  Yeah, most GNOME apps use CSD but every app can look like developer wants. They have freedom to design own apps, we have freedom to use (or not) it. That's it and saying that GTK forces CSD is just wrong, because GTK doesn't force CSD.

                  Originally posted by ngraham View Post

                  They can't force us to use CSDs for our apps any more than we can force them to abandon them.
                  They are not forcing CSD. It's totally optional feature in GTK. As I like CSD I hope it will stay optional not because integration problems. It's mostly solved and if app have wrong theme without match with rest of DE then having SSD it's not great improvement. I hope it will stay optional because more choice is always better for developers and users.
                  Last edited by dragon321; 12-01-2019, 03:56 PM.

                  Comment


                  • #39
                    ngraham
                    I can't judge what specifically is broken inside KWin, so I can't establish connections if any report might be a duplicate. I can only look at the result, which is utterly broken for many years, and apparently everybody stopped caring about it or got used to stutter as "normal".

                    It's a matter of seconds to judge whether compositor vsync is broken or not by simply opening vsyntester.com, playing a video in mpv with --video-sync=display-resample and comparing it vs. no compositor.

                    Comment


                    • #40
                      Originally posted by ssokolow View Post

                      I'm not at all a fanatic. I'm saying that it's ludicrous and juvenile for any set of toolkit developers to unilaterally declare that the only acceptable solution is for others to either add their toolkit as a dependency or reinvent part of it. (The latter of which will still produce an inferior result unless their theming system is also reinvented.)
                      You have people who have differing opinions on what a compositor should and shouldn't do and what a toolkit should or shouldn't do. Neither is right or wrong and they both have their advantages and dis-advantages. We're quite fortunate in that Linux is open enough for people to have these choices.

                      The GNOME devs don't think a compositor should be drawing parts of windows, that's their choice to make and it's not a "wrong" choice given it's what other platforms (non-Linux excl. Android) are doing. KDE developers think the compositor/window manager should draw window decorations, and coming from the X world where there isn't one native toolkit, that makes sense too.

                      Comment

                      Working...
                      X