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
    schmidtbag
    Senior Member

  • schmidtbag
    replied
    So much butthurt over something so inconsequential...
    I've used interfaces with and without CSD, and it's never been a significant issue to me either way. Sure, anyone would prefer consistency, but as long as the software functions the way I need it to, I really don't see why decorations matter that much.

    Leave a comment:

  • JonathanM
    Senior Member

  • JonathanM
    replied
    Originally posted by ThanosApostolou View Post
    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.
    This seems very unlikely to me, maximizing an application is not just changing the dimensions of a window. The state of the window is changed and the placement of window is also adjusted (the latter would not happen using this method and as far as I know the information necessary to do this client side is missing on wayland). You can also have an application filling the screen while that application is not maximized. Tiling windows in a window manager like gala and I assume mutter also changes them to a maximized state while the application does not fill all available space.

    What might be going on is that the application is gradually resized when maximizing which causes many redraws (which may be more expensive than resizing a window with server side decorations depending on how the compositor handles resizing/maximizing (it may, for example, choose to only redraw the frame)) which slows this down, but that would be caused by the compositor and not the toolkit.

    Looking at the Gtk source code I can find no evidence of the behavior you described: xdg_toplevel_unset_maximized or zxdg_toplevel_v6_unset_maximized is called requesting the compositor to maximize the window.

    Leave a comment:

  • ThanosApostolou
    Phoronix Member

  • ThanosApostolou
    replied
    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)?
    ThanosApostolou
    Phoronix Member
    Last edited by ThanosApostolou; 21 October 2019, 06:14 AM.

    Leave a comment:

  • Venemo
    Senior Member

  • Venemo
    replied
    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.

    Leave a comment:

  • Shiba
    Senior Member

  • Shiba
    replied
    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.

    Leave a comment:

  • Guest
    Guest

  • Guest
    Guest replied
    Long life to Xorg (it works fully).

    Leave a comment:

  • ElectricPrism
    Senior Member

  • ElectricPrism
    replied
    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.
    ElectricPrism
    Senior Member
    Last edited by ElectricPrism; 21 October 2019, 12:09 AM.

    Leave a comment:

  • flower
    Senior Member

  • flower
    replied
    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

    Leave a comment:

  • Venemo
    Senior Member

  • Venemo
    replied
    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?

    Leave a comment:

  • flower
    Senior Member

  • flower
    replied
    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?

    Leave a comment:

Working...
X