Titlebar shows buttons for unavailable actions

[WhyNotHugo]

Steps to reproduce

0. Run a compositor which doesn't support at least one of: minimise, window_menu, maximise, fullscreen
1. Start telegram-desktop

In my case, I am reproducing this on swaywm, which can run nested on another compositor.

Expected behaviour

The titlebar should not show buttons for actions that have been reported as unavailable by the compositor.

Actual behaviour

The titlebar shows buttons for actions that have been reported as unavailable by the compositor.

Operating system

Alpine Linux (Edge)

Version of Telegram Desktop

telegram-desktop-5.7.2-r1

Installation source

Other (unofficial) source

Crash ID

n/a

Logs

Logs with WAYLAND_DISPLAY=1 indicate that telegram-desktop is being informed of capabilities:

[4280808.291] {Default Queue} xdg_toplevel#39.wm_capabilities(array[8])

The 8 here is the size of the array in bytes. There is a single item in this array, the int32 3, which means fullscreen.

[WhyNotHugo]

In Settings > Advanced > Window Title Bar, there is a "Use Qt window frame" checkbox. This renders a different titlebar, but it also renders buttons for unavailable actions.

[WhyNotHugo]

Somewhat tangential: only the Qt titlebar implementation actually renders the title.

[ilya-fedin]

It follows org.gnome.desktop.wm.preferences button-layout on settings portal and Gtk/DecorationLayout on xsettings.

[WhyNotHugo]

The log shows that the compositor is already informing telegram of its capabilities. Why query an external service for compositor capabilities? One need to write a custom implementation to expose this GNOME-specific setting via the portal API.

[ilya-fedin]

The log shows that the compositor is already informing telegram of its capabilities. Why query an external service for compositor capabilities?

1. I don't think there's a Qt API for this
2. The GNOME API is of user preference, not capabilities, so it will have to be queried even if there's a Qt API for Wayland capabilities. It also works just fine with all major DEs including KDE.

[WhyNotHugo]

Qt is informed of these capabilities and then doesn't let applications query them?

I think this is worth reporting upstream, what do yo think?

---

The XDG settings portal doesn't allow a user to configure settings. It merely relays configurations exposed by separate "portal implementation" daemons. If I wanted to expose a org.gnome.desktop.wm.preferences setting, I'd have to write a custom daemon to expose this value.

GNOME and KDE already include a daemon that exposes this and other custom settings, but I hope you'll understand that this is ridiculously over-engineered, considering the value is already being passed by the compositor to the client.

[ilya-fedin]

Qt is informed of these capabilities and then doesn't let applications query them?

As far as I'm aware, they don't have the goal of wrapping each and every native API... That's what they told when I was asking APIs for various Wayland things.

I think this is worth reporting upstream, what do yo think?

I reported it ~2 years ago: https://bugreports.qt.io/browse/QTBUG-104630

If I wanted to expose a org.gnome.desktop.wm.preferences setting, I'd have to write a custom daemon to expose this value.

You can use xdg-desktop-portal-gtk and set the value via gsettings. That's what KDE does.

[ilya-fedin]

considering the value is already being passed by the compositor to the client

Well, it's not the same as I explained. The compositor could support all those actions but the user may want to have only close button for example (the GNOME's default). It also provides the order and the side of the buttons.

[ilya-fedin]

As far as I'm aware, they don't have the goal of wrapping each and every native API...

There's still no API even for xdg-positioner and the only way to position menus is via global positioning which is a way bigger & older thing and leads to various bugs with menus, what do you want about some capabiliities most people don't even know about...

[ilya-fedin]

Qt's API is a lowest common denominator, mostly copying WinAPI.

[WhyNotHugo]

Thanks for the references.

Qt's API is a lowest common denominator, mostly copying WinAPI.

I've noticed this pattern with dozens of bugs in applications that cannot be fixed due to limitations in Qt. Each of these bugs in not a big deal, but together, they result in an experience of hitting on bug after another, continuously.

[ilya-fedin]

I'm doubt any other toolkit provides API for this particular issue, btw.

[WhyNotHugo]

Firefox doesn't render minimise or maximise buttons on the top right corner; it only renders the close button.

I don't run any other application which renders its own titlebar. All other applications rely on compositor decorations, even Qt6 applications like audacious, or nheko. Only Telegram renders its own bar.

BTW: the non-Qt window frame renders a titlebar with no title. Is this also part of the same issue?

[ilya-fedin]

Firefox doesn't render minimise or maximise buttons on the top right corner; it only renders the close button.

It's because it uses g_object_get(gtk_settings_get_default(), "gtk-decoration-layout") which in turn gets the value from org.gnome.desktop.wm.preferences button-layout on gsettings. If you had xdg-desktop-portal-gtk installed that bridges gsettings values to portal, you would see the same with tdesktop. And then you would be able to use gsettings set org.gnome.desktop.wm.preferences button-layout '' to get rid of titlebar icons from firefox, tdesktop, any gtk application and any other application with custom toolkit reading gtk settings.

[ilya-fedin]

BTW: the non-Qt window frame renders a titlebar with no title. Is this also part of the same issue?

It's just how the designer drew it on mockup.