Announcement

Collapse
No announcement yet.

KDE Still Isn't For Client-Side Decorations But Has Been Selectively Using Some D.W.D.

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

  • KDE Still Isn't For Client-Side Decorations But Has Been Selectively Using Some D.W.D.

    Phoronix: KDE Still Isn't For Client-Side Decorations But Has Been Selectively Using Some D.W.D.

    With word this week that KDE's Dolphin file manager has adopted a hamburger menu that has re-ignited the discussion once more over client versus server-side decorations for the KDE desktop...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    You just restarted the discussion with this thread.

    Still, just hoping KDE allows users to choose between SSD and the new hybrid (which seems like a fair compromise).

    Comment


    • #3
      The issue is rather that KDE, mainly Kwin always bugged out with CSD clients.

      Them finding a solution on accident is nothing surprising, it seems like most things that work on KDE work by accident.

      And a note for KDE fans, CSD does not mean Gnome CSD, it means that not two but one party is responsible for drawing the Windows. There is nothing that would stop KDE apps from drawing decoration that looks and works exactly as the server side decoration KDE uses. In fact if you used a KDE app on a gnome desktop, you already used KDE apps with CSD. For the usual known reason, those CSDs don't bug out on Gnome.

      Comment


      • #4
        Yet again, trying to make people confused between header bars and CSDs, which are not the same thing. Although the former requires the latter.

        Pretty much all the criticisms of CSD's in that blog post are criticisms of header bars, not CSD. Windows and macOS (and even some GTK apps) have normal title bars with CSD.

        Comment


        • #5
          Originally posted by Britoid View Post
          Yet again, trying to make people confused between header bars and CSDs, which are not the same thing. Although the former requires the latter.

          Pretty much all the criticisms of CSD's in that blog post are criticisms of header bars, not CSD. Windows and macOS (and even some GTK apps) have normal title bars with CSD.
          I'll agree that I think header bars are a bad idea, to be ripped out and replaced if at all feasible (If I had the time, I'd try writing a replacement for Flatseal that doesn't look like a badly GNOME-skinned tablet app), but my arguments against CSD in general are more in the vein of the Arcan complaints.

          I hated how every version of Windows I used before I left Windows XP for Mandrakelinux 10.0 would have its titlebars go non-responsive when the application's message loop got bogged down in certain ways, while I've never had X11 suffer from that problem.

          I fight hard to ensure my applications are as consistent as possible.

          I actually use all that stuff KWin stuffs into the context menu for window decorations, and I like being able to customize the layout of my titlebar buttons and have everything obey.

          Need I go on?

          Comment


          • #6
            From Graham's post:
            They would either lose a lot of space used for dragging the window, or else lose the ability to click-and-drag-and-release to activate headerbar items in menus, comboboxes, pop-up menus, etc. You can’t have both with CSD headerbars.
            ... Huh??
            If you try to actually use a GTK app in GNOME for less than one minute and try that out, you'll find out that widgets on the headerbar can be clicked or dragged, and dragging them moves the window. Zero technical reasons why a headerbar widget wouldn't be able to act as draggable area. It's also intuitive and easily discoverable.

            Unless the point here (although badly written) is that you can't have a widget that functions by dragging its contents and also have it draggable to move the window, which would be... peculiar?

            (And of course there's the matter of CSD != headerbars as already pointed out by other users.)

            Edit: nevermind, I think I got it. Graham must be referring to the workflow of clicking on a menu, not releasing the mouse button until the cursor is on a menu item, and then releasing the button to select that item. So yes, it technically conflicts with a headerbar widget being draggable to move the window around and, in fact, hamburger menus on GTK apps don't allow for that.
            Question: is this important, one way or the other?
            Last edited by chocolate; 16 May 2021, 08:46 AM.

            Comment


            • #7
              Originally posted by Alexmitter View Post
              The issue is rather that KDE, mainly Kwin always bugged out with CSD clients.

              Them finding a solution on accident is nothing surprising, it seems like most things that work on KDE work by accident.

              And a note for KDE fans, CSD does not mean Gnome CSD, it means that not two but one party is responsible for drawing the Windows. There is nothing that would stop KDE apps from drawing decoration that looks and works exactly as the server side decoration KDE uses. In fact if you used a KDE app on a gnome desktop, you already used KDE apps with CSD. For the usual known reason, those CSDs don't bug out on Gnome.
              Yeah. A lot of us treat CSD to be synonymous with "the GNOME HIG's implementation of CSD" when that's technically not the case. I know I have before.

              But in regards to how KHamburgerMenu works and header bars in general, my biggest issue with the GNOME HIG is that it moved all the window management controls to a submenu aside from close and double clicking the header bar. It would be cool if GNOME and KDE could agree on a CSD design that's minimalist by default but allows a KHamburgerMenu button to expand out to more window management controls or even allowing us to do a double header bar that's only used for expanding window management controls if we're cluttering up the header bar. The extra bar would be halfsize or smaller because all it is for is window management...basically bringing back what a titlebar does now in a way that should hopefully work for both minimalist and non-minimalist users. All I can do is suggest that.

              You know, that could work both ways with an extra bar going down if a user wants to add more application controls from the app's menu.

              My KDE title bar includes Close, Max, Min, Roll up/down, and show on all desktops. When multitasking all those are handy so it's a bit annoying when they're buried in a menu somewhere. It used to include the ? help function. The problem is that most of the time I've used the ? for help it was basically as helpful as a tool tip. If the tool tip was helpful I wouldn't have used the ? thingy. It's a catch 22.

              Comment


              • #8
                Originally posted by Alexmitter View Post
                The issue is rather that KDE, mainly Kwin always bugged out with CSD clients.

                Them finding a solution on accident is nothing surprising, it seems like most things that work on KDE work by accident.

                And a note for KDE fans, CSD does not mean Gnome CSD, it means that not two but one party is responsible for drawing the Windows. There is nothing that would stop KDE apps from drawing decoration that looks and works exactly as the server side decoration KDE uses. In fact if you used a KDE app on a gnome desktop, you already used KDE apps with CSD. For the usual known reason, those CSDs don't bug out on Gnome.
                ... ... it is evident that you are a fan of Gnome and this post testifies to it.

                Comment


                • #9
                  Originally posted by chocolate View Post
                  It's also intuitive and easily discoverable.
                  That's debatable at the very least.
                  Why should I think that a button or a switch or a text edit field, which have their very distinct usage, would act also as a draggable handle?
                  It's not intuitive and it never was.
                  By the way, I think that on MacOS headerbar widgets do not drag the window, ergo it's not even familiar for someone coming from outside of Linux, specifically from outside of Gnome.

                  Originally posted by chocolate View Post
                  Unless the point here (although badly written) is that you can't have a widget that functions by dragging its contents and also have it draggable to move the window, which would be... peculiar?
                  Of course that's exactly the point. And it's not because one would want a slider that can also be used to drag the window, but because sliders "break the rule".
                  By the way, in my opinion MacOS implementation is way better, because first there is no subtle functionality and second the fact adding widgets to the headerbar quickly reduces the draggable area keeps the amount of widgets to a minimum, which again in my opinion fits with the purposes of a headerbar

                  Comment


                  • #10
                    Originally posted by chocolate View Post
                    From Graham's post:

                    ... Huh??
                    If you try to actually use a GTK app in GNOME for less than one minute and try that out, you'll find out that widgets on the headerbar can be clicked or dragged, and dragging them moves the window. Zero technical reasons why a headerbar widget wouldn't be able to act as draggable area. It's also intuitive and easily discoverable.

                    Unless the point here (although badly written) is that you can't have a widget that functions by dragging its contents and also have it draggable to move the window, which would be... peculiar?

                    (And of course there's the matter of CSD != headerbars as already pointed out by other users.)

                    Edit: nevermind, I think I got it. Graham must be referring to the workflow of clicking on a menu, not releasing the mouse button until the cursor is on a menu item, and then releasing the button to select that item. So yes, it technically conflicts with a headerbar widget being draggable to move the window around and, in fact, hamburger menus on GTK apps don't allow for that.
                    Question: is this important, one way or the other?
                    In all fairness he says "GNOME-style client-side decoration headerbars" early on in the blog post and from there on refers to everything as CSD or headerbar.

                    Comment

                    Working...
                    X