! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
Make CSD optional
Status:
RESOLVED: MOVED
Product:
Libxfce4ui
Component:
General

Comments

Description haarp 2020-01-14 11:41:51 CET
Hi!

With 4.15/4.16 picking up speed, client-side decorations (CSD) have been added to libxfce4ui. Simon's blog has some more information: https://simon.shimmerproject.org/2020/01/14/xfce-4-14-maintenance-and-4-15-updates/

I've been testing this new version and I'm not a fan for these reasons:

- CSD title bars are **massive**
- I don't want app elements in my title bars (such as the search bar in the Xfce Settings Manager) - it's one of the reasons I'm avoiding Gnome apps like the plague.
- Xfwm4 themes do not work on CSD windows (unless such support is planned??)
- Non-Xfce/Gnome windows do not use CSD, leading to heavy inconsistencies across CSD and non-CSD window styles

I would be very very thankful if CSD could be made optional, or at least be made to look and behave exactly like traditional title bars. Please consider it.

Cheers!
Comment 1 haarp 2020-01-15 22:36:03 CET
Oh dear. With CSD being enabled now, they're starting to appear in many GTK windows too, such as file pickers.

Another reason to avoid them: They are bad usability, as mentioned in Medium's interesting "Make. It. Simple." series. Have a look at the "Button" section: https://medium.com/@probonopd/make-it-simple-linux-desktop-usability-part-2-d34b86fd9b79

(btw. this series has praised Xfce quite a lot)

CCing Simon because I'm not sure if anybody received an email for this bug.
Comment 2 Simon Steinbeiss editbugs 2020-01-15 22:59:11 CET
There is a similar thread ongoing on the Xfce users Mailinglist, following on the panel's 4.15 release.

We discussed the options enumerated here and the majority of active core developers voted for option 2 (https://wiki.xfce.org/releng/4.16/roadmap/general_ui/csd).

So while I appreciate your point of view, we will not make them configurable, this would simply add a lot of code to all kinds of components. And I hope you trust us on this, we're not trying to break things for anyone - we're still the same people that released Xfce 4.14.

If users only want to use CSD for Xfce's settings dialogs but not the rest you can use the corresponding xsetting to disable CSD in the toolkit's native dialogs:
xfconf-query -c xsettings -p /Gtk/DialogsUseHeader -s false
Comment 3 haarp 2020-01-16 09:36:54 CET
Hey Simon,

> There is a similar thread ongoing on the Xfce users Mailinglist, following on the panel's 4.15 release.

Where do I find this list? It's not listed on https://mail.xfce.org/. In fact, none of these lists are particularly active. Is there a hidden list where I might follow dev efforts, decisionmaking, etc?

> we will not make them configurable

I see. But then I have to wonder, how are you going to handle visual inconsistency between CSD and non-CSD windows? Even if all Xfce windows support CSD, there will *always* be third-party apps that don't. Gnome's approach of "screw everything not made by us" is bad.

I think Xfwm is going to have to adapt by trying to replicate the CSD style as closely as possible.

On the positive side, this could also do away with the need for a separate Xfwm theme.

On the negative side, this will kill the flexibility and configurabilty of window decorations provided by Xfwm. Furthermore, CSD and non-CSD windows will behave differently. Non-CSD windows don't get Xfwm's features, such as tiling by dragging to screen edges, or the right-click-resize provided by bug 12026.

So either we lose some of Xfwm's features, or you'll have to teach GTK how to handle Xfwm's features. I feel there's a lot of work and head-scratching ahead to get things to work consistently.

> If users only want to use CSD for Xfce's settings dialogs but not the rest you can use the corresponding xsetting to disable CSD in the toolkit's native dialogs

Can you please expose this somewhere in the Appearance settings? Xfce has way too many hidden settings.

Thanks!
Comment 4 haarp 2020-01-16 09:38:40 CET
s/Non-CSD windows don't get Xfwm's features/CSD windows don't get Xfwm's features/
Comment 5 Simon Steinbeiss editbugs 2020-01-17 09:14:43 CET
I was referring to https://mail.xfce.org/pipermail/xfce/2020-January/thread.html

In terms of decision making, there was never a "transparent" or "democratic" process. Usually the current maintainer took the decision alone and that was it (after all, you know that we're all working on Xfce as a hobby, in our spare time). In this case - as we expected this to be a decision that could spark discussions - we took a (closed) email vote in the core development community to make sure all of us were ok with the change.

> I see. But then I have to wonder, how are you going to handle visual inconsistency between CSD and non-CSD windows? Even if all Xfce windows support CSD, there will *always* be third-party apps that don't. Gnome's approach of "screw everything not made by us" is bad.

There is only a visual inconsistency and that has always been around. Obviously themes like Greybird try to cover up the inconsistency by providing an Xfwm4 theme that matches the CSD contained in the Gtk+ theme. Many other quality themes also do that and will continue to do so in my opinion.

I'm not sure how much flexibility is lost - you can still reposition the window buttons (min, max, close) with CSD.

Agreed, the "roll up" feature is lost with CSD. Not sure how many people were aware of this or made use of it.

> Can you please expose this somewhere in the Appearance settings? Xfce has way too many hidden settings.
This is not an Xfce setting, it's a Gtk setting. It exists whether we want it or not.

I'm not sure yet whether we will expose it in the UI - keep in mind that it will result in an inconsistent setup with Xfce's settings dialogs (and some apps I guess) using CSD, and the dialogs using SSD and people will complain and report bugs about it.
The hidden settings are usually intended for distributors to configure a meaningful default for people.
Comment 6 haarp 2020-01-17 11:56:18 CET
Thanks for your answer, Simon. I accept that CSD won't be made optional, but I'd like to help make their use bearable.

Personally, I can live with them, but not with window content in the header bars. That's too much Gnome, bad usability, and I'm certain you'll be risking some of the goodwill Xfce has gathered for being a traditional looking DE.


> DialogsUseHeader: This is not an Xfce setting, it's a Gtk setting. It exists whether we want it or not.
> I'm not sure yet whether we will expose it in the UI - keep in mind that it will result in an inconsistent setup with Xfce's settings dialogs (and some apps I guess) 

I would claim the opposite. DialogsUseHeader is going to lead to more inconsistency. Most applications outside of Gnome's bubble do not use such things.

How about this proposal: Have an option in Appearance settings to switch "Show app content in headerbars" on/off.
If on: Xfce windows are free to add window content to their headers and DialogsUseHeader is enabled.
If off: Xfce windows refrain from adding window content to their header, approximating classic headerbars. DialogsUseHeader is disabled.

This way CSD can be used without enforcing usability/visual changes. If an user uses predominately Gnome software, enabling this setting will improve visual consistency. If the user doesn't, disabling it will improve visual consistency.


> There is only a visual inconsistency and that has always been around. Obviously themes like Greybird try to cover up the inconsistency by providing an Xfwm4 theme that matches the CSD contained in the Gtk+ theme. Many other quality themes also do that and will continue to do so in my opinion.

I've tested a couple of themes, including Greybird and Numix. None match the CSD theme very well.

Here's where the tested themes are inconsistent with non-CSD windows:

- Title font and font style
- Title font alignment
- Window button layout
- Presence of subtitles
- Titlebar height (theme issue?)
- Window button styles (theme issue?)

The first 3 items could be removed from customization in favor of using the GTK theme's. But I'll really miss the sticky window button :(
The last 2 are possibly theme issues.

And I really hope CSD will finally solve bug 11808. Without the ability to use bug 12026, it's a real pain.
Comment 7 Simon Steinbeiss editbugs 2020-01-17 14:33:09 CET
> Thanks for your answer, Simon. I accept that CSD won't be made optional, but I'd like to help make their use bearable.

That's great! You could start by testing the changes so far (e.g. in the xfce-test docker container or another kind of test system).

> I would claim the opposite. DialogsUseHeader is going to lead to more inconsistency. Most applications outside of Gnome's bubble do not use such things.

Well as I said this setting exists already, so even with Xfce 4.12 or 4.14 you can enable/disable it - with the aforementioned result.


> If off: Xfce windows refrain from adding window content to their header, approximating classic headerbars. DialogsUseHeader is disabled.

This is currently the case anyway. If you look at the screenshots, all settings dialogs have the oldschool layout and don't have any extra buttons (apart from the searchbox in settings manager) in the headerbar.
Regarding Xfce apps: We'll see. In general that's up to the respective maintainers.
If you look at the example of taskmanager, that doesn't look bad or unusable or inconsistent to me: https://wiki.xfce.org/_media/releng/4.16/roadmap/general_ui/taskmanager-csd.png?w=200&tok=9233c0

Also, Xfce apps like Catfish have used headerbars and CSD for a while already.

> But I'll really miss the sticky window button :(

We may be able to bring this back for XfceTitledDialog. I'm less optimistic for "roll up".
Comment 8 haarp 2020-01-19 18:35:40 CET
> You could start by testing the changes so far (e.g. in the xfce-test docker container or another kind of test system).

I'm already staying up-to-date with dev releases and some patches on top :)


Ok, I'd like to shift the topic of this discussion from "CSD or not" to "App elements in titlebars or not".

> Well as I said this setting exists already, so even with Xfce 4.12 or 4.14 you can enable/disable it - with the aforementioned result.

But it only concerns dialogs. This:

> Xfce apps: We'll see. In general that's up to the respective maintainers.

is another matter. And I dearly hope that apps will keep it configurable. Ideally there would be a global switch to toggle elements in the titlebars for all applicatons.

> If you look at the example of taskmanager, that doesn't look bad or unusable or inconsistent to me

None of the CSD apps are unusable. But it does break conventions and hurt usability. It's non-intuitive and needlessly long-winded. You can check the other parts of the series I mentioned in comment 1 for more details, its really quite interesting. And in my personal opinion, it also just looks really bad.

Once some of the Xfce apps use this approach, others are much more likely to follow suit. Not to mention that to an outsider, this will invalidate Xfce's "classic" look, which was one of its best selling points.


Anyway, I think I made my point. As an user, I don't make decisions, and I accept that. I'd just like there to be a choice, or at least a discussion on the matter. Please close this bug at your discretion.

Cheers!
Comment 9 mgruber_72 2020-02-05 18:35:00 CET
I'm with haarp on this subject. Those CSD title bars waste so much space. Not everyone has a 32" screen. Plus even on larger screens it's a step back in terms of usability and consistency.

I really don't know what the point of this is.
There would be so many other fields where improvement would be needed, like the afore mentioned bug #11808 or the inconsistent keyboard shortcuts (bug #11455).
Comment 10 ToZ editbugs 2020-02-06 05:15:37 CET
I'd also like to chime in here. I run Xfce directly from the git tree and can see all of the enhancements. My preference is also for some sort of configurable on/off switch for this functionality (understanding the complexity and additional code required).

Here are a couple of forum threads where this is being discussed:
- https://forum.xfce.org/viewtopic.php?id=13687
- https://forum.xfce.org/viewtopic.php?id=13689

My concerns are around lost window manager functionality and consistency of look. I make extensive use of the window shading feature and will sorely miss this functionality. In addition, titlebar configuration will no longer be consistent. With xfwm, we can select which controls and in which positions to place them. With CSD, to get this functionality back, all of these functions will need to be re-created for each individual app/component. Although incompatibility between CSD and non-CSD windows exists now, it is possible to create a non-CSD environment using Xfce and avoiding CSD apps. When Xfce moves over to CSD, will will lose this ability.

Perhaps we can pursue some sort of official survey or poll through the website to get a feel for user desire for this change.
Comment 11 haarp 2020-02-20 13:27:27 CET
I sort-of managed to get rid of CSD for now. Note that ths is just a hacky workaround.

Step 1: Install and set up gtk3-nocsd (https://github.com/PCMan/gtk3-nocsd.
Step 2: Add these rules to ~/.config/gtk-3.0/gtk.css:

/* CSD: collapse leftover when using gtk3-nocsd */
headerbar {
	margin-top: -100px;
	border-bottom-width: 0;
}
/* but not when functional elements are in it */
headerbar button,
headerbar spinbutton,
headerbar entry,
headerbar separator {
	margin-top: 103px;
	margin-bottom: 3px;
}

This should restore traditional window decorations and also get rid of the leftover CSD (but only if there are no functional elements in it. If there are, the CSD will remain visible and usable).

I'm no expert at CSS, and GTK's weird subset of CSS with its limited selectors and properties doesn't make things easy, so it may not work everywhere. Seems to work fine for me tho.
Comment 12 Git Bot editbugs 2020-05-25 23:02:56 CEST
-- GitLab Migration Automatic Message --

This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/xfce/libxfce4ui/-/issues/14.

Please create an account or use an existing account on one of our supported OAuth providers. 

If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests

Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev

Bug #16375

Reported by:
haarp
Reported on: 2020-01-14
Last modified on: 2020-05-25

People

Assignee:
Simon Steinbeiss
CC List:
5 users

Version

Version:
4.15.1

Attachments

Additional information