Request/Propose: A solution to the debate CSD vs windows manager

salome · 2020-05-11 09:55:02

Hi everybody,

as you know, XFCE 4.16 will use CSD:

https://wiki.xfce.org/releng/4.16/roadm … ral_ui/csd

Some people like it, some people don't , some people may prefer to use his favorite windows manager.

I think that the best option is: give users the power to choose.

There is an interesting project, called gk3-nocsd , that can disable CSD from your desktop

but actually you have to install it ad modify your environment variability for make it work. It's not for all kind of users.

My propose: add to XFCE project gtk3-nocsd, with a graphical front-end tool that make you able to enable / disable CDS as you want

Last edited by salome (2020-05-11 09:56:04)

slavko · 2020-05-17 13:06:03

THIS would be awesome!

I'm using Mint 19.3 (with the addition of Xfce 4.14 PPA) and all I had to do was to install gtk3-nocsd from software manager. So, it wasn't hard to install, but having it integrated into Xfce itself (with the GUI switch) would be even better.

One thing though:
It seams that developers are using new ways to implement CSDs now, making it difficult for gtk3-nocsd to override CSDs. This is what I mean:

Yes, CSD is gone, but dialog looks ugly.

(Also, some Mint-specific tools cannot be de-CSD-ed, but that's not Xfce dev's responsibility.)

Is there a place where we can express our concerns and give our arguments about this?

PS: I've been reading this forum (and enjoying it, and learning from it) for a long time, but never bothered to post something. This single proposition made me to create account and "step out". Thank you, salome, for bringing this to table.

File Manager · 2020-05-17 21:19:22

I don't know what Xfce 4.15 looks like right now (development version), but I assume CSDs are being implemented.

GTK 4 slated for release this year won't support gtk3-nocsd because gtk3-nocsd relies on something that won't be supported in GTK 4.

Either stay with Xfce 4.14 or use MATE 1.24 which is similar and has an improved window manager (invisible borders for resizing, work to eliminate tearing etc.)

I like Xfce, but transitioning to MATE is easy when the time comes. The biggest loss by not using Xfce is the wealth of information in this forum in my opinion.

Or learn to like CSDs, that's an option that less stubborn users than myself may choose.

The CSD issue has already been discussed on this forum. See these threads:
https://forum.xfce.org/viewtopic.php?id=13687
https://forum.xfce.org/viewtopic.php?id=13689

denyer · 2020-05-20 22:55:24

Yeah, not looked back from Plasma on my main PC personally. After settings things up initially it just works.

On one specific issue I have with CSD (vertical maximising), @XfceNation pointed out a workaround -- shortcuts can be assigned via Settings > Window Manager > Keyboard, and this still works with CSD windows. Doesn't allow shading/rollup of those windows, though.

janp · 2020-05-27 07:41:59

salome wrote:

Hi everybody,
as you know, XFCE 4.16 will use CSD:
https://wiki.xfce.org/releng/4.16/roadm … ral_ui/csd
Some people like it, some people don't , some people may prefer to use his favorite windows manager.
I think that the best option is: give users the power to choose.
There is an interesting project, called gk3-nocsd , that can disable CSD from your desktop
https://github.com/ZaWertun/gtk3-nocsd
but actually you have to install it ad modify your environment variability for make it work. It's not for all kind of users.
My propose: add to XFCE project gtk3-nocsd, with a graphical front-end tool that make you able to enable / disable CDS as you want

I tried gtk3-nocsd and it does not work with some application, e.g, the Opera browser, Microsoft Teams for Linux, Mattermost for Linux and, I suspect, a lot of others based on the Electron platform.
These desktop applications are built like (and eventually they are) web applications and following mainly the Microsoft implementation of the "flat design" . Moreover these apps, at least under Xfce, do not retain the minimal shadow effect that they have under Win10, so they are barely distinguishable from the content of other windows in background.
This is to say that without a border and a title around these windows, the applications become difficult to use.
All these applications are built with CSD, so they draw a "titlebar" which is a horrible-thick rectangle that is used also for other purposes like placing search controls, tab controls and so on besides the standard minimize/maximize/close buttons. The drag area is limited by the presence of these controls, and obviously they do not follow the standard of the window manager in use, so you cannot, e.g., move the window to another workspace or roll it up. It is possible to force a WM titlebar over them (Kde kwin has this option but can be done also in xfwm, a thing wich I am asking again here and now the Developers to do , please please), but you'll end up having partially the same controls on the titlebar and on the CSD app.
Even if the CSD-ed app can work without CSD (this is the case of the apps from Gnome), by removing the redundant controls, it will normally be different from the classical apps, because menus and other controls will maintain their (bad) CSD style.
This disaster was triggered by the adoption by both CSD and "flat design" which will make the Linux desktop an horrible mess of unconfigurable, indistinguishable windows, each one potentially with their own controls made in different ways.
Unfortunately Xfce has chosen to adopt CSD too, a choice that they motivate in the document that you linked that tries to demonstrate that the CSD adoption will bring advantages but they - IMHO - are not so big and that can be seen also as disavantages, but also carries disavantages that are real and serious and can have the very nasty outcomes that are described above.
Unfortunately it looks that we have to adapt to choices that at firts sight seem illogical and that subtract configurability and bring important limitations to the users.

Last edited by janp (2020-05-27 07:45:49)

MountainDewManiac · 2020-05-28 06:50:51

So where's the sensible fork of Xfce 4.10, lol?

0strodamus · 2020-05-29 05:10:59

MountainDewManiac wrote:

So where's the sensible fork of Xfce 4.10, lol?

I'm hoping there will be one. I'm staying on 4.10 as long as possible.

MountainDewManiac · 2020-05-29 07:06:59

0strodamus wrote:

MountainDewManiac wrote:
So where's the sensible fork of Xfce 4.10, lol?
I'm hoping there will be one. I'm staying on 4.10 as long as possible.

The only problem with that route is... Well, look at MATE, lol. A bunch of people decided (rightly) that it'd be a great idea to kind of keep GNOME 2.x alive - so they spent a lot of time not doing so roll . First time I tried to use MATE, everything I tried was all screwed up (in other words, was nothing like GNOME 2.x), and the last time it was at least five percent better, but still looked/felt like they'd taken some other DE and fiddled with it to give it that "50-yard GNOME 2.x look," to - sort of - loo the same... IF you were standing on the other side of the road, in a driving rainstorm, looking across the road, through your window, and at your computer. While it was just sitting there in the desktop, not doing anything.

What really should happen is for all the developers who aren't in favor of driving away 98% of the established Xfce user base in hopes of being able to capture... what, maybe 2% of the current GNOME3 users, for them to vote the sadist(s) off of the team.

But I'm guessing that he/she (or them, if it's actually more than ONE person) must be the only one who has a working Internet connection, or something equally necessary to modern computer software developers. Or maybe the person holds some kind of trademark and/or rights to "Xfce," and everyone else feels they're stuck with him/her and his/her awful idea of pulling a "Coke."

You know, a "Coke." What Coca Cola did some years back when some... genius high muckity muck at the company decided that it'd be a great idea to change the formula from one that was keeping many millions of satisfied customers happy every year to one that might score a few hundred thousand Pepsi customers. I've heard THAT didn't last long. Although I suppose the idiot received a million dollar bonus initially, for coming up with the idea, and several million more dollars as part of his/her severance package at the next board meeting when he was asked to "resign to pursue other interests" or however the suits word it so that they can immediately go start screwing up another company instead of having to sign up for unemployment.

I wonder if that's what happened to Microsoft's Windows OS? Maybe it started out as a great idea, concept, et cetera and then Bill Gates said, "Hey, I have an idea..." That guy always was a good talker - otherwise, he'd have been in jail long ago.

File Manager · 2020-05-29 20:30:23

The background from the Pale Moon forum (Off-Topic section that needs an account to be viewed)

From https://developer.gnome.org/gtk4/3.98/ch32s02.html:
First, menus are going to be eliminated and replaced with popovers:
The GTK developers wrote:
These widgets were heavily relying on X11-centric concepts such as override-redirect windows and grabs, and were hard to adjust to other windowing systems.
Menus can already be replaced using GtkPopoverMenu in GTK 3. Additionally, GTK 4 introduces GtkPopoverMenuBar to replace menubars. These new widgets can only be constructed from menu models, so the porting effort involves switching to menu models and actions.
"X11-centric concepts." Oh yeah. Like no other windowing system has ever supported menus. Reality check: Wrong! Practically every windowing system on the planet has menu support, even ancient Mac OS and the Apple Lisa. Even Wayland, which is supposed to be relatively bloat-free, has support for the window types required to draw menus.
Next, and possibly even worse, toolbars are going to be removed:
The GTK developers wrote:
Toolbars were using outdated concepts such as requiring special toolitem widgets. Toolbars should be replaced by using a GtkBox with regular widgets instead and the "toolbar" style class.
I don't care if there's a "toolbar" style class -- based on the GNOME-style user interfaces these days, I'd have to imagine even the style class is going eventually.
Somebody even decided to remove GtkContainer and GtkBin. They didn't even give a reason for that one:
The GTK developers wrote:
The abstract base class GtkContainer for general containers has been removed. The former subclasses are now derived directly from GtkWidget, and have class-specific add() and remove() functions.
Isn't the whole reason for object-oriented programming to avoid re-inventing the wheel? I mean, come on. Now all former container widgets must implement all that code that used to be implemented in GtkContainer.
There are even more examples of annoying little things they've done in that article I linked to. I just don't have time to rattle them all off.

Every traditional GTK application will be gone with GTK4. So Xfce devs can't do anything. GTK must be forked. So this is what The Squash is working on. The discussion is happening on the Pale Moon forum currently, but The Squash also posted here on the Xfce forum so if there are questions just bump that thread with relevant questions.

https://forum.xfce.org/viewtopic.php?id=14023

Since a lot has already been discussed on the Pale Moon forum here are some quick notes:
The GTK fork "STLWRT" (drop-in replacement) will be based on GTK2 with GTK3 compatibility and automatically shred headerbars and CSDs per application (customisable application database) and accommodate that functionality in menubars and toolbars with regular titlebars. It will initially be delivered as a STLWRT live iso with LXDE, MATE and Xfce and a few former headerbar applications. Maybe June/July 2020 is realistic for initial release.

I don't expect mainstream distro adoption, but if we can keep at least one traditional desktop (MATE seems the one most suited IMO) during the GTK4 cycle a lot is won IMO. This means you should be able to use a traditional GTK desktop and traditional GTK applications for another 10 years. Possibly longer if STLWRT can integrate GTK5 changes. Wayland support is also planned.

Any STLWRT related questions can be answered by STLWRT developer The Squash in the Xfce forum thread linked above.

MountainDewManiac · 2020-05-30 12:20:20

The real problem is, we use a DE that is developed/maintained by a group of people who have chosen to use someone else's toolkit. So... are you going to fork Xfce - and all of its associated components - too?

If you do, and you use your own toolkit, I'll give it a try when it gets released. Otherwise...

viggo · 2020-07-26 14:49:07

MountainDewManiac wrote:

The only problem with that route is... Well, look at MATE, lol. A bunch of people decided (rightly) that it'd be a great idea to kind of keep GNOME 2.x alive - so they spent a lot of time not doing so . First time I tried to use MATE, everything I tried was all screwed up (in other words, was nothing like GNOME 2.x), and the last time it was at least five percent better, but still looked/felt like they'd taken some other DE and fiddled with it to give it that "50-yard GNOME 2.x look," to - sort of - loo the same... IF you were standing on the other side of the road, in a driving rainstorm, looking across the road, through your window, and at your computer. While it was just sitting there in the desktop, not doing anything.

I really liked the Gnome DE and its workflow but CSD's are a pain in the.... so I switched to Mate, and now I was looking into switching to Xfce again after years, but... what, CSDs? No, thanks...

eriefisher · 2020-07-26 17:26:31

I've been using XFCE for many years now but this CSD thing have got me a bit fed up. The reason I ended up with XFCE is I wanted a complete desktop but found KDE just too much and I really disliked Gnome, especially Gnome 3. When I started there was no Mate(just gnome2 afaik) or other complete desktops and XFCE just fit the bill perfectly. It could look any way you wanted it to. It was Gtk based and light on the resources. It pretty much had something available for every function built in and no extra bloat.

Now with this CSD thing I have been avoiding applications that use it(which can be done) but it's getting more difficult. Even with the NO-CSD the look and feel is lost. This is not a solution. Because of this I have been looking for another option and I may have found one. I've been playing around with LXQT. Although it's a blend of GTK and QT it reminds me a lot of why I started with XFCE. It's pretty light, fast and configurable. I haven't made any final decisions yet but this is where I will likely end up if the CSD path continues.

I just don't understand GTK. There are still a lot of things in GTK3 that don't work properly or as expected yet they're push to 4 and forgetting about it all. I think this is really going to stir the pot.

denyer · 2020-07-26 21:04:30

You might find this a reasonable option -- someone's forked libxfce4ui to disable CSDs;

https://forum.xfce.org/viewtopic.php?pid=58987#p58987

Xfce Forum

Sub domains

#1 2020-05-11 09:55:02

Request/Propose: A solution to the debate CSD vs windows manager

#2 2020-05-17 13:06:03

Re: Request/Propose: A solution to the debate CSD vs windows manager

#3 2020-05-17 21:19:22

Re: Request/Propose: A solution to the debate CSD vs windows manager

#4 2020-05-20 22:55:24

Re: Request/Propose: A solution to the debate CSD vs windows manager

#5 2020-05-27 07:41:59

Re: Request/Propose: A solution to the debate CSD vs windows manager

#6 2020-05-28 06:50:51

Re: Request/Propose: A solution to the debate CSD vs windows manager

#7 2020-05-29 05:10:59

Re: Request/Propose: A solution to the debate CSD vs windows manager

#8 2020-05-29 07:06:59

Re: Request/Propose: A solution to the debate CSD vs windows manager

#9 2020-05-29 20:30:23

Re: Request/Propose: A solution to the debate CSD vs windows manager

#10 2020-05-30 12:20:20

Re: Request/Propose: A solution to the debate CSD vs windows manager

#11 2020-07-26 14:49:07

Re: Request/Propose: A solution to the debate CSD vs windows manager

#12 2020-07-26 17:26:31

Re: Request/Propose: A solution to the debate CSD vs windows manager

#13 2020-07-26 21:04:30

Re: Request/Propose: A solution to the debate CSD vs windows manager

Board footer