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.

cross-posted from: https://lemmy.zip/post/57302675

an article explaining why GNOME should support SSD, but also arguing against the reasons often given for why they shouldn’t

If someone could repost this to r/GNOME I would appreciate it, since I don’t have a reddit account.

  • ninepointeight@lemmy.ml
    311·
    2 days ago

    This is the main argument the GNOME developers use to justify why they don’t support SSD. This is true, xdg-decoration is an “unstable” protocol, and wayland was originally designed with only CSD in mind.

    This is the main argument they use but this is not the main reason. The main reason is “design”. SSDs are not a part of GNOME HIG or GNOME’s vision. It’s not that they just ‘don’t like it’. They actively want to kill it, at least in their own ecosystem.

    The original 2018 “CSD initiative” blog post has TLDR on top saying, " Let’s get rid of title bars. Join the revolution!" so they consider this a “revolution”.

    • Blisterexe@lemmy.zipOP
      16·
      2 days ago

      I 100% agree, but I didn’t want to come across too accusatory in my article so I chose to indirectly adress it in this paragraph:

      The real problem is the idea that GNOME project shouldn’t cater to [people who want SSD]. 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.

      Since both approaches are used, and liked, miscellaneous advantages and disadvantages of either approach are irrelevant, and so are other arguments pertaining to design. This is why I haven’t brought them up.

      basically saying I think their vision doesn’t matter when it comes to supporting things like that for third party apps.