Vlákno názorů k článku KDE ladí Wayland, Miguel Ojeda hlásí konec experimentu: Rust se stal součástí jádra Linux od dr_ak - Nechci si dělat domněnky, ale zajímá mě, proč...

Mimochodem na této implementaci se pracuje, ale bůhví kdy bude hotová.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3797

O tom jsem mluvil, navíc extenze není finální (EDIT: doplnil jste, že už pracují na podpoře v GNOME):

"Warning! The protocol described in this file is currently in the testing phase."

Ještě oprava pro moje předchozí sdělení:

> Osobně vím o jediném problému, a to je XDG decoration, kde GNOME touto cestou tlačí, aby aplikace přešla z X11 na Wayland (nicméně knihovna emulující okraj okna už má témata, která hlavní distribuce imitují dobře).

X11 aplikace mají server side dekoraci. Ale Wayland aplikace jsou tlačeny do přechodu na Gtk, jinak nedostanou "nativní" okraje okna. Nicméně to řeší libdecor (používán např v SDL), problémy jsou pak už jen záležitost distribuce:

https://www.reddit.com/r/linux/s/zW3kkziAnD

14. 12. 2025, 13:07 editováno autorem komentáře

No a pak jsou tu protokoly, které se snaží Gnome aktivně blokovat.

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/179

https://www.youtube.com/watch?v=pLzxP4WFe5U

Nejen GNOME. Wayland jako takový to neumí. Takže jsme zpátky u roztříštěnosti Linuxu, kdy neprogramuješ pro Linux, ale pro konkrétní desktopové prostředí.

Já jsem ochotný pochopit, že Wayland je hlavně display protokol a tyhle speciality ohledně umístění oken nechce.

Jenže oni nenabízí alternativu.

A ty window managery by potřebovali jednotné API, aby to aplikace nemusely psát na několikrát. Což je na druhou stranu to samé, co dělá Wayland.

Tak ať to nazvou desktop-api-windows nebo to oddělí do separátního repozitáře a nechají to spravovat lidmi od desktopů a aplikací. Výsledek bude sice nakonec stejný, ale potěší to puristy.

Oni ponukaju alternativu - CSD. Co je presne to, co konkurencne systemy robia. Ano, pod windows aj macos su dekoracie client-side (ono to ma dopad na mnozstvo bufferov, ktore treba drzat vo VRAM a kolkokrat ich treba kopirovat, preto su CSD efektivnejsie).

Rozdiel je, ze pod windows aj macos je povinne nalinkovat urcite kniznice, inak sa k displej serveru nedostanete. No a tieto kniznice okrem pripojenia k displej serveru riesia aj dalsie veci, okrem ineho aj dekoracie, fonty, widgety, farbicky. Na linuxe sa s kompozitorom bavime cez socket zadefinovanym protokolom, takze co si aplikacia nespravi sama, to nema, lebo vraj bloat v knizniciach. No tak si aplikacia musi riesit dekoracie vo vlastnej rezii.

Dalsi problem je, ze riesenie pre dekoracie potrebuje dotiahnut pomerne velky stack: rendering fontov (=> pribuda freetype, fontconfig, pango, harfbuzz), rendering widgetov (chceme tam mat menu a tlacitka, ak maju byt konzistentne, tak to znamena aj tak cely gtk alebo qt), temy (pre widgety aj pre preferovane farby). Aplikacia toto vsetko bude mat tak ci tak, ale kompozitor to inak nepotrebuje.

Ono aj rozsirenie pre server-side decoration je koncipovane ak volitelne; tak sa netreba zavzdusnovat nad fragmentaciou. CSD je dostupne vzdy, SSD je optional, pre tych, co si ho vydupali. Pre tych, co chcu minimalisticke kniznice, je tu libdecor.

Problém nedovoleného SSD (Server Side Decorations) v GNOME je, že aplikace nevypadá nativně, když si musí okraje kreslit sama. Takže fragmentace tu je. I když použiju libdecor, tak budu mít problém ve Snap, FlarPak apod.

15. 12. 2025, 11:47 editováno autorem komentáře

Aplikacia nikdy nebude vyzerat nativne.

Ak pouziva Gtk, bude mat CSD. Ak pouziva nieco ine, ci uz Qt alebo inu kniznicu, tak widgety a font rendering v dekoraciach budu ine ako v aplikacii.

Podobne pod Kwin - ak aplikacia pouziva Qt, bude vyzerat rovnako ako kompozitor. Pokial pouziva hocico ine, ako Qt, nebude vyzerat nativne.

Na to, aby vyzerala nativne, musel by byt jeden povinny platformovy framework - ako je Cocoa alebo win32 user32.dll.

Já ale nemluvil o dekoracích. To je maličkost. Já mluvil o problémech s protokoly na pozicování myši, přesouvání oken a full screen. Což všichni považují za zodpovědnost window manageru, ale pak zapomínají, že pro window managery taky neexistuje jednotné API.

Bez toho ten Linux ale nepůjde používat. Naštěstí vývojáři Waylandu uznávají chybu a některé chybějící funkce po letech dodělali.