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

[flower]

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

[ElectricPrism]

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.

[Guest]

Long life to Xorg (it works fully).

[Shiba]

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.

[Venemo]

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.

[ThanosApostolou]

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

[JonathanM]

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.

[schmidtbag]

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.

[ThanosApostolou]

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.

Yeah I didn't mean that the actual resizing is done exactly how I wrote, but I was talking more about how the calculation is done and that it is more expensive.

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.

Hmmm maybe I have misunderstood something then, thx for the comment.

[heliosh]

2020? why the hurry? Or do they mean 2020s?