GTK and QT applications ignore the COSMIC header

[BrodieRobertson]

Applications like Alacritty draw the COSMIC window decorations correctly

But applications like Firefox or PCManFM which are GTK3

Or applications like OBS which is QT5

Do not draw the COSMIC window decorations even though I know they support SSD as they use it correctly on KDE.

[cameronbosch]

This might be worse than originally thought: Here are some GTK Flatpaks with missing minimize & maximize buttons.

[git-f0x]

This might be worse than originally thought: Here are some GTK Flatpaks with missing minimize & maximize buttons.

You might need to retoggle the buttons in Window management settings, and potentially enable Apply this theme to GNOME apps in Experimental settings. The configured window control buttons appear for me on both native and flatpak GTK apps.

[cameronbosch]

You might need to retoggle the buttons in Window management settings, and potentially enable Apply this theme to GNOME apps in Experimental settings.

Unfortunately, I've already tried that. It doesn't seem to make the situation different. Do you have any other ideas?

[Adam-Cosner]

If you specifically mean the style of the header bars, that's due to the fact that most of these apps use client side decorations instead of server side decorations.

[mmstick]

Can you get the output of gsettings get org.gnome.desktop.wm.preferences button-layout? This is what defines window control placement in GTK. Maybe Flatpaks aren't getting the correct values from the host?

[mmstick]

I know that there's a Wayland protocol that allows applications to define whether they prefer client-side or server-side decorations. And if this configuration parameter is not defined, the compositor will use its preferred default. COSMIC prefers client-side decorations, so if an application didn't define that they prefer server-side, it will default to using their client-side decorations. This is probably what's happening to Qt applications at least.

[cameronbosch]

Can you get the output of gsettings get org.gnome.desktop.wm.preferences button-layout? ... Maybe Flatpaks aren't getting the correct values from the host?

That might be the problem here, as the value returned by that command is:
':minimize,maximize,close'

[mmstick]

I think we could fix it by setting the config through the settings portal

[Drakulix]

Toolkit-native decorations are expected where supported. Cosmic doesn't force Server-side decorations by design. We just provide them as a fallback for applications, that either don't have client-side decorations or don't prefer to use them.

[adiee5]

that's interesting. So, it's not possible to tell protocol-wise whether the application provides CSD only as a fallback or when it actually prefers CSD?

[dominichayesferen]

Is there any chance the design to use CSDs as the compositor level fallback preference can become a discussion later down the road?

I suspect that, especially once Qt theming is added and GTK potentially gets XDG_DECORATION support (it's a Merge Request currently), revisiting this topic may be valid as there is certainly merit, in my opinion at least, to have the compositor's own fallback (for applications that don't decide) become server-side decorations (it avoids inconsistent adw-gtk3 decos in Firefox and the likes, and should avoid Qt's fallback CSDs(?) existing above COSMIC Qt styling).

[PoisonFrog]

It should just force server side decorations if possible. If you let each toolkit apply their own CSD everything will look all over the place in COSMIC. The way it is in COSMIC right now looks bad, and I don't know any desktop environment that let every other app apply their own decorations. What was the point of making an effort to apply a GTK theme that looks similar to the COSMIC theme you are using if the plan is to make everything look like a mess by letting each app apply their own decorations?

[Bochrm]

Toolkit-native decorations are expected where supported. Cosmic doesn't force Server-side decorations by design. We just provide them as a fallback for applications, that either don't have client-side decorations or don't prefer to use them.

The thing is, in cases like with Qt toolkit, some GTK apps like Firefox, etc, CSD is implemented/toggled specifically for software not to break on GNOME because of their refusal to provide fall-back decorations (which I think is quite unreasonable, the fact that toolkits and apps can't rely on standard Wayland behaviour, having to tailor to GNOME because only they think the compositor shouldn't handle decorating).

Naturally either the decorations bear ugly/placeholder design, in some cases with awkward resize/dragging/maximizing/tiling behaviour, or you have a developer having to bundle something like libdecor to work and look good on GNOME, which will in turn look out of place in COSMIC because of it's CSD preference that has an app assume GNOME behaviour (despite support for 'fall-back' decorations which the app might actually prefer, relying on KDE's SSD preference). All of this being evident in OP's screenshots

In my little opinion having the compositor prefer (not force) SSD akin to KWin is the better, least nuanced option many things considered (and devs/users seem very much fine with it), some being that if an app prefers or requires CSD and doesn't expect to be decorated, then it'll clearly just not request SSD.
If an app is fine with SSD, then that would probably look better anyway by avoiding potential inconsistency in both UI and UX, and there shouldn't be any expected impact to functionality (would be funny if a dev implemented cool extra functionality in a client-side title bar but allowed the compositor to hide it away). I don't see why SSD should be viewed as last resort mechanism thing

While I'm personally fine with CSD being left default, I think this should really remain open for discussion or at least be taken by COSMIC devs into account down the line
I know that much of this is more of a general Wayland issue (the whole SSD/CSD compositor preference thing that seems quite problematic, especially with GNOME's application breaking behaviour of not implementing xdg-decoration that also has to be accounted for). But it will probably be years before (and if) this is sorted out on that side

Maybe the whole prefer CSD/fallback to CSD thing should also be looked into on Qt's side, but I digress

[dominichayesferen]

It should just force server side decorations if possible. If you let each toolkit apply their own CSD everything will look all over the place in COSMIC. The way it is in COSMIC right now looks bad, and I don't know any desktop environment that let every other app apply their own decorations. What was the point of making an effort to apply a GTK theme that looks similar to the COSMIC theme you are using if the plan is to make everything look like a mess by letting each app apply their own decorations?

KWin. KDE Plasma fallbacks SSDs but allows CSDs to be used if desired.

Keep in mind here that forced SSDs would cause browsers' titlebar situations to be permanent (as the titlebars with tabbars inside are obviously CSD powered), just with COSMIC titlebars instead, alongside adding bars to the built-in COSMIC applications therefore is logically a no-go: