Announcement

Collapse
No announcement yet.

Xfce 4.16 To Drop GTK2 Support, Explore Some Client-Side Decorations

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

  • #21
    Introduction of new features without properly fixing existing issues is questionable:
    • There are a number of HiDPI issues
    • FreeSync does not work properly when XFCE's window compositor is enabled
    • Multi-monitor configuration interface with different monitor resolutions is incomplete
    • XFCE 4.12/4.14 is generating core dumps (if core dumps are enabled) at a rate of several per week
    Maybe, a better idea of how to improve overall Linux desktop experience would be to enforce use of std::shared_ptr throughout all GUI elements in GTK libraries and applications.

    #define ptr std::shared_ptr
    #define make std::make_shared

    Comment


    • #22
      Originally posted by Mavman View Post

      Totally agree!

      For a regular computer, Plasma without any doubts.
      For old or special machines where all resources count I definitely prefer LXQt!

      Both avoid CSD and I couldn't agree more with the choice!
      my only problem is kio. if plasma would integrate something like kio-fuse deep enough (eg i can copy file links and have the fuse link - not the kio one) i'd happily use it.
      i dont know about lxqt though. do they use kio too?

      Comment


      • #23
        I didn't imagine people would be so passionate about who draws their title bars. Why does it matter so much, as long as they serve the same purpose?

        Comment


        • #24
          Originally posted by Venemo View Post
          I didn't imagine people would be so passionate about who draws their title bars. Why does it matter so much, as long as they serve the same purpose?
          i wouldn't care if they all would look and work the same.
          but most apps i saw which used headerbars or csd look alien to my desktop. i like consistency

          Comment


          • #25
            Originally posted by Venemo View Post
            I didn't imagine people would be so passionate about who draws their title bars. Why does it matter so much, as long as they serve the same purpose?
            Having used CSD for 4? years I can say it reduces scope of app functionality and when a app requires more than a hand full of dialogs the hamburger menu becomes a mess very quickly.

            In tiling window managers like i3 and sway the extra window controls have no function other than to "fill up space" and core application functionality is often oversimplified for a tiny "phone interface" or equivalent.

            Such design goals cripple the professional desktop user who need as much power available to them as possible with as much ease as possible without hiding features away.

            The file menu is a tried and true workflow concept in use over 20 years. Complex apps like Gimp, Inkscape, Blender, Krita, etc... wouldn't have a chance organizing so many functions for users.

            My compromise would be keeping the File menu and having a "hide for all apps" global making the menu available by a searchable tree menu.
            https://github.com/p-e-w/plotinus

            Then quite literally the "tool bar" would literally overlap the exact features of CSD and the user could select if they choose to hide their file menus or not. Throw in a window controls button that can be dragged/dropped to the toolbar, and drag-and-drop search menu.

            This preserves legacy, offers nearly the exact same functionality of CSD, preserves compatibility with other window managers and puts the decision and power in the users hands where it belongs.

            I like app consistency, and to me XFCE always had one up on Gnome for not having CSD. It's not that I don't want the client drawing the titlebar or file menu, it's just the CSD usually means eliminating the titlebar and file menu and hodgepodges elements of each along with the toolbar into a single bar that is much more limited.
            Last edited by ElectricPrism; 10-21-2019, 12:09 AM.

            Comment


            • #26
              Long life to Xorg (it works fully).

              Comment


              • #27
                Originally posted by duby229 View Post

                That's bull. What CSD proved is it breaks look and feel, most devs refuse to duplicate common window management capability, it increases white space and reduces usabilty. None of which is a good thing.

                Seems quite convenient to me.

                Comment


                • #28
                  Originally posted by ElectricPrism View Post
                  Having used CSD for 4? years I can say it reduces scope of app functionality and when a app requires more than a hand full of dialogs the hamburger menu becomes a mess very quickly.
                  CSD is only a technical detail of what part of the software draws the title bars for you. CSD does NOT equal the header bars you see in Gnome apps. Xfce can implement them however they see fit.

                  Comment


                  • #29
                    CSD lets the application developers and users decide. Hating CSD is hating powerful applications and Freedom.

                    We cannot have that behaviour in this establishment.

                    Comment


                    • #30
                      Ignoring the headerbar discussion (which in my opinion is a subjective decision by the app creator), can anyone explain me why CSD are considered more technically advanced by so many people?

                      In my experience if a buggy CSD client hangs then you cannot resize it or use the minimize/maximize/close buttons at all since they are all controlled by the client (which is really bad). Also someone had told me (if I remember correctly he was the creator of gtk3-mushrooms) that when maximizing a CSD app it doesn't know about the screen resolution so it just increases its size by steps until it reaches the maximum size. That's why you can see that maximizing a CSD app is always a bit sluggish even in Wayland whereas all resize actions perfectly smooth for Server Side Decorations' apps when they are supported by the Wayland compositor. Desktops hide this sluggishness with animations but still I consider it a technical regression of CSD over SSD. Also I believe that since Wayland Compositors have getting rid of all the X overhead, doing window actions on SSD apps can be handled more efficiently over all than CSD apps.

                      So, can we say that CSD is technically worse than SSD, even if it gives more design control at app creators and the possibility of headerbars without duplication of titlebar (I personally like CSD+headerbar appearance much more, even if I currently use KDE)?
                      Last edited by ThanosApostolou; 10-21-2019, 06:14 AM.

                      Comment

                      Working...
                      X