> GTK's team is still fine (barely)

Really? Isn't GTK where the CSD (client side decoration) is being forced onto every app, with no way to use native/normal window manager borders? It seems rather widely despised:

https://news.ycombinator.com/item?id=16241923

https://old.reddit.com/r/xfce/comments/lcj7cq/why_is_csd_bad...

That's more of a GNOME effort, if I'm being honest. It's a feature that's provided via GTK's libraries, but the whole "we're going to add CSD and you're not going to do anything about it" has been more of a GNOME sentiment[0].

[0] https://blogs.gnome.org/tbernard/2018/01/26/csd-initiative/

App developers will design their apps in a certain way and will add features that they think benefits the app. Some will add CSD if they think it's beneficial and others won't. What is it that you would want to do about that? That's always been how it is. If you were in charge of designing the app then you'd be the one going to meetings and writing the code.

>Isn't GTK where the CSD (client side decoration) is being forced onto every app

No. GTK doesn't have any preference for decorations, you can use either one when writing GTK apps: https://docs.gtk.org/gtk4/method.Window.set_decorated.html

The app developer gets to choose what decorations they support. Some app developers will choose to only support a certain type of decorations; that's an intentional design decision made as part of the app. In the past, GNOME app developers have chosen to use CSD and XFCE developers didn't, but there seems to be a shift from them towards CSD too. I've also seen some XFCE users saying they like the CSD.

Maybe the people that don't mind, or like it keep more quiet. I prefer it, been a CSD user since before CSD itself, with Winamps rolled up UI.

>I prefer it, been a CSD user since before CSD itself, with Winamps rolled up UI.

That is it, but somehow you don't see it??? I mean is so obvious/// You could have Winamp or you could have an application with a window in the form of a circle but this days GNOME decided that you can ONLY have CSD and old apps that use SSD or non-GNOME apps that use SSD should switch to SSD... so you ahve 2 issues

1 GNOME is removing the option to have both SSD and CSD , and forces you into CSD only

2 GNOME does not provide(maybe things changed and someone forced those arrogant bastards to support some legacy app that RedHat needs) any support for SSD apps.

I don't understand how you're having those issues. GNOME has never had the option to have both CSD and SSD. When GNOME apps used GTK2, SSD was the only option. When GNOME apps started moving towards GTK3, CSD became the only option. What you're asking for is a new feature because GNOME never supported both.

Legacy apps using X11 will use the legacy X11 decorations. Those should still work. For Wayland apps, those were never working correctly if they didn't support CSD. What you're again asking for is a new feature, there are no legacy Wayland apps that will depend on that functionality because it never existed in GNOME Wayland.

> SSD was the only option. When GNOME apps started moving towards GTK3, CSD became the only option. What you're asking for is a new feature because GNOME never supported both.

Really? , You should just hide the Window titlebar , and paint your own CSD, titlebars were not forced on you https://developer.gimp.org/api/2.0/gtk/GtkWindow.html#gtk-wi... , this is how for example splashscreens are implemented or fancy non rectangular windows , but to be honest I am not 100% sure if GNOME2 was also an asshold and disabled this GTK feature just to be spacial, if you can confirm then let me know if I am right then you need to acknowledge the fact that SSD was not forced on you(not Qt,not GTK, not even Windows/OSX forced SSD on you )

Sure, the feature existed in GTK but what I mean there is that GNOME 2 apps didn't use that. They never painted their own CSD. Sure some apps did for splash screens but not for ordinary app windows. Then when GNOME 3 happened they all redesigned their apps to only use CSD. They didn't implement SSD in Wayland because it wasn't part of the design and by then all the GNOME 2 apps were already gone anyway. That API is even still present in GTK4, the reason you saw a change is because the apps (the callers of the API) changed how they use it.

But the issue we have with GNOME is not that they changed their own apps to CSD, the issue is that their Window Manager does not paint the SSD for non-GNOME app, I hope this is clear now or let me try to simplify it

Before

- you could have both CSD and SSD application run on GNOME

After

- you are FORCED to implement CSD on GNOME because their Window Manager will not paint the SSD for you, even for old application that existed before GNOME3 was created.

It would make sense for GNOME to support this old applications or toolkits that do not implement CSD , I really hope sanity will prevail over designer ego (it happened at Apple so there is a chance it will happen at GNOME after a few years of feedback)

>you are FORCED to implement CSD on GNOME because their Window Manager will not paint the SSD for you, even for old application that existed before GNOME3 was created.

No, this is not true at all. Old applications and toolkits that existed before GNOME 3 was created will use X11, and the legacy decorations will still work there.

>No, this is not true at all. Old applications and toolkits that existed before GNOME 3 was created will use X11, and the legacy decorations will still work there.

OK, good news then for old apps and games , is there a solution ready for new applications like Qt,Electron ones that were not created for GNOME? Can you resize them on Wayland or you are forced on X11 ? If you do not use Wayland is he Window Manager still implementing the SSD or they removed the code (I think I read something about code getting removed but I am might be thinking about something else).

So my question if I were to test GNOME+Wayland will this work correct:

1 old games , games that use DOXbox or emulators

2 new games in Wine or native

3 Qt or other apps like Intellij,Thunderbird, Visual Studio Code, VLC, Slack (does GNOME still has no system tray for Slack/email clients ?)

4 is GTK still recommended for cross platform development? isn't cross platform support and GNOME design in a contradiction? any such example of a cross platform GTK4 complex application

I am sorry if my knowledge is a bit outdated, I am no longer reading Linux news ,podcasts or Linux reddits (I got tired about reading all the small drama stuff, the big news will reach me somehow anyway)

1. Those will probably use SDL which has got support for wayland CSD: https://github.com/libsdl-org/SDL/pull/4068

2. Wine apps will probably have to draw the win32 decorations. Native apps can implement their own decorations or can use GTK or Qt to draw their decorations.

3. Qt does have its own CSD decorations, VLC should be able to use that. Intellij is a Java app so I'm not sure about that one but Thunderbird should use GTK decorations. The rest are Electron apps and Electron has a PR open for CSD: https://github.com/electron/electron/pull/29618

A system tray can be added to GNOME with an extension.

4. GTK is not a cross platform toolkit like Qt where it tries to draw everything with native widgets, but it is a portable toolkit meaning that you can port applications to other platforms and they will more or less look the same. I don't know anyone using it ship Windows applications, some improvements have been made to get it working better on Windows though: https://www.collabora.com/news-and-blog/blog/2021/03/18/buil...

OK, so I am not doing any desktop app development this days but if I will do I will not write any special code for GNOME.

> GTK is not a cross platform toolkit like Qt where it tries to draw everything with native widgets

Just a correction, Qt does not use native widget, they have code that will adapt and paint the thigns too look and work as native widgets, so for example they have button groups that when you use it say for OK-Cancel buttons it will change it to Cancel-OK on different platforms (some platforms have the order reversed). Also Qt will paint the OK/Cancel button icons on KDE but not on Windows/GNOME . So in fact Qt devs put the effort in and wrote code and themes to get things look native, use the native file dialogs, use the native notifications, system tray, the native paths etc (not ike the other toolkit that doesn't care about integration, theming and configuration)

Yeah, that goes against everything Wayland.

a. Some discussions become the target of trolling and it's necessary to lock threads, unfortunately it happens sometimes. If somebody has made a rude comment then you may want to report that as a code of conduct violation. The developers are volunteers and don't have infinite time to handle all the work that's thrown at them. The disagreement with Pop!_OS was disappointing but I don't know who else you can blame for that, if Pop!_OS wants to go their own way then that is completely their decision. They aren't forced to contribute upstream and I'd say that's good for them and their goals.

b. There isn't really any funding to pay to fix those issues. They're being fixed by volunteers, so progress is slow.

c. I have no idea what this means, extensions are still there.

d. There are issues with Flatpak but all the other options are worse and are more unstable. Before Flatpak, there was just no way for upstream developers to make an "official" packaging for apps. The theming interfaces haven't really changed because those didn't really exist, those were a hack for the entirety of GNOME 3. Having one person implement a design and then gather feedback on it from the community is how open source works. If the community wants it then they'll use it, if they don't then they'll use something else. I'm confused how else you'd expect it to go. Talk is cheap, putting working prototypes in front of the community and then gathering feedback from there is what gets things done.

I also don't really understand why you're saying this makes them the bad guys or comes at the expense of the rest of the community. Like, none of this affects KDE. KDE has their own middleware libraries and makes their own changes. They don't depend on any GNOME libraries. Even XFCE that depends on some libraries like GTK doesn't really have to deal with any of this. GNOME's issues with extensions don't affect them at all because they don't use the GNOME shell, they can package their apps with whatever they want and they don't have to use Flatpak, they probably won't use libadwaita or if they do they'll heavily modify it, etc.