Cet article est aussi disponible en français. This article contains quite a few technical terms, which I will explain these in the following paragraphs, those that are already familiar with these terms may skip to the next section. A basic understanding of linux and it’s desktop environments is assumed. Server side decorations (SSD) is the term for when when the application’s titlebar is drawn by the system and client side decorations (CSD) is the term for when the applications draws it’s own titlebar. KDE prefers the former, while GNOME prefers the latter. KDE and most other desktop environments supports both, while GNOME only supports CSD.
  • hello_hello [comrade/them]@hexbear.netEnglish
    4·
    4 days ago

    Here we go again (channeling the inner Matthias Clasen, one of the lead engineers in GTK)

    Many apps handle CSD poorly.

    Fix the apps that don’t support Linux. There is a difference between porting to GNU/Linux and actual support. Hire formal engineers (not enthusiasts burning the midnight oil) to port to freedesktop and wayland or accept contributions/improve tooling.

    libdecor is the worst of both worlds because you get the space inefficiency and lack of integration of a traditional titlebar, with all the inconsistency and lack of user customization of an integrated titlebar.

    Agree, apps and toolkits should implement their own libdecor. Libdecor was a stopgap measure for porting applications, but it’s not an end all solution.

    Supporting SSD would solve this

    No, as the compositor cannot make decisions for the app’s window bar and thus will choose the least common denominator approach (that being, libdecor). This is what KDE does, it’s KDE’s decision, but it cannot be everyone’s decision.

    The issue with doing that on linux is that the design of the titlebar can vary so wildy depending on the environment that having CSD’s that “feel native” is a bit of a losing battle. Offering the option of SSD for non-GNOME apps on GNOME and vice versa would go a long way to making applications feel more native for users that value that sort of thing.

    This did not explain why this would be the case. An app’s “look and feel” is much more than the titlebar. Padding, font, colors, widget design, animations, sound, etc all play into it. Even the way the settings menu is presented varies differently from app to app, from desktop to desktop.

    A lot of users on other desktops are frustrated by GNOME apps not supporting SSD, breaking if SSD is force-enabled.

    GNOME applications use the adwaita platform toolkit which explicitly does not want the compositor to force window decorations on it as the window bar of these apps are a design feature. GNOME applications look like GNOME applications, this is intentional. As far as I know there isn’t a toolkit that is so similar to adwaita that forcing a different titlebar wouldn’t disrupt the application.

    GNOME apps optionally supporting SSD would make many users of other desktops very happy indeed.

    Customer is always right mindset is not the deciding factor in technical decisions.

    This fragmentation only makes the linux desktop less attractive to developers and, importantly, makes application developers less likely to adopt more modern standards such as wayland.

    App developers do not have a choice in adopting wayland. Legacy xserver will disappear in only a few years from distributions and xwayland is a stopgap measure. There is no fragmentation, CSD has always been part of wayland and will always be a part of it.

    However, wayland was also initally designed without screenshare or global keybinds, standards that GNOME had since adopted.

    This is not part of wayland it is part of xdg-desktop-portals which is an abstraction separate from wayland (but used in wayland-based desktops to access desktop resources).

    The real problem is the idea that GNOME project shouldn’t cater to the first group. It would be like GNOME not supporting xdg-file-chooser and saying that each app should ship their own file picker. But GNOME does support it, and only apps that wish to implement their own file picker do so.

    Ditto with top, this is part of the portal spec but also that some GNOME engineers in passing have mentioned that they don’t actually want apps to make the file picker portal the de-jure implementation of file picker, if the app has its own way of doing file picker that’s more suited to it than it should use that.

    In this scenario, the GNOME app would remove the integrated window title and controls.

    Deeply unserious.

    GNOME’s lack of support for server side decorations is the single biggest issue with the GNOME desktop environment right now,

    If a fake protocol designed to ape proprietary systems that doesn’t actually work both in theory and practice is the largest “issue” of GNOME then I would say GNOME has done pretty well.

    Anyway article was written in 2022 so L bozo author GNOME will hold the line on Client-side’ist thought.