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


    • #32
      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; 01 December 2019, 03:56 PM.

      Comment


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


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


          • #35
            Originally posted by Gusar View Post
            tildearrow Is it just me or is 144Hz giving off a very GhostOfFunks vibe?
            No, it's not just you. 144Hz has been acting more like Griffin/GhostOfFunkS/Mentalist lately, but an upgraded version of them. Not only he disturbs threads and demeans those who don't follow him, but he does some sort of psychological tricks to rack up vast amounts of likes on his propaganda posts.

            This is the final comment about 144Hz that I post on this thread.

            Comment


            • #36
              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.
              Researching the topic related to xdg-decoration from GNOME perspective, it turned out the method for implementing SSD (which applied for X11 apps from which decoration is done by X11 backend) to a Wayland client isn't viable enough. The current suggestion in progress is an independent library.
              See https://gitlab.gnome.org/GNOME/mutte...17#note_553315

              Comment


              • #37
                Originally posted by Morty View Post

                And the last 24 years have shown that CSD is a bad idea and has only create visual mess and more unnecessary work for developers.

                The touted "gain" from CSD supporters have given some fancy looking "toy" applications like media players, which most of the time are used full screen or minimized anyway. Or the ability to shave of a few rows of pixels at the top of applications. Maybe a gain 15 years ago, but with today's high resolution screens, not so much.
                Yeah, and it's fuckin hysterical too, they save a few pixels at the top but those same gnome apps are almost -entirely- white space anyway... What about all the other 70 to 95 % of visible space that is -completely- empty.... Wasted pixels on a titlebar is the very least of wasted space gnome devs should be worrying about....

                Talk about hypocritical.... That's the worst hypocrisy I hear about....
                Last edited by duby229; 02 December 2019, 03:09 AM.

                Comment


                • #38
                  Originally posted by duby229 View Post

                  Yeah, and it's fuckin hysterical too, they save a few pixels at the top but those same gnome apps are almost -entirely- white space anyway... What about all the other 70 to 95 % of visible space that is -completely- empty.... Wasted pixels on a titlebar is the very least of wasted space gnome devs should be worrying about....

                  Talk about hypocritical.... That's the worst hypocrisy I hear about....
                  headerbars != client side decoration

                  GTK still uses client-side decoration under Wayland even if you don't use a headerbar.

                  Comment


                  • #39
                    Originally posted by Britoid View Post

                    headerbars != client side decoration

                    GTK still uses client-side decoration under Wayland even if you don't use a headerbar.
                    Which, -by definition- breaks look and feel... (You make that asinine statement as if you think it's somehow a good thing)

                    And that's what Plasma devs have to deal with, unfortunately...
                    Last edited by duby229; 02 December 2019, 03:33 AM.

                    Comment


                    • #40
                      Originally posted by 144Hz View Post
                      duby229 User report from the other side: Everything on GNOME just works. The user experience gets more and more pleasant as headerbar designs evolve and expand.

                      It might not benefit you personally but at least it helps the majority of users. And that’s what counts
                      Sorry, but I disagree. Just my opinion here, no possible way broken look and feel and enormous amounts of white space benefits -anyone- at all. Not Gnome, not KDE, not app devs, and most especially not end users.

                      EDIT: And no, not everything "just works" on Gnome, themes break constantly as just one example.... (And let me not even get started on the literal dozen extensions or more needed to get it somewhat useful as an end user desktop interface, which also constantly break)
                      Last edited by duby229; 02 December 2019, 04:47 AM.

                      Comment

                      Working...
                      X