Povodne diskusia vznikla o tom, ze ine systemy vedia shader efekty na regionoch jednotlivych surfaces kompozitora a kwin nie. Odpoved bola, ze kwin to vie tiez, ale neexistuje na to standardny wayland protokol (nieco, co ine systemy tiez vobec nemaju) a preto na to pouziva privatne api -- zatial co v danych inych systemoch je akakolvek komunikacia s kompozitorom cez privatne api.
Nato diskusia odbocila k systemovym toolkitom, kde sme si ukazali ze dnes sa mnoztvo tych systemovych toolkitov blizi lilmitne k nule. Co sme si nepovedali bolo to, ze definicia systemoveho toolkitu bola taka, ze on jediny ovlada privatne api k window manageru ci kompozitoru a ak chce niekto iny vytvorit iny toolkit, musi linkovat k tomuto systemovemu a pouzivat ho ako proxy.
Mimochodom, spominany Qt takto na Windows a MacOS funguje dodnes (na Windows skrz win32 a na MacOS skrz Cocoa).
Z danej definicie vyplyva, ze Qt nie je a nebude systemovym toolkitom na ziadnom linuxe. Lubovolny iny toolkit ho totiz nepotrebuje, vie komunikovat s waylandom alebo x11 priamo, standardnym sposobom. (To iste plati pre Gtk -- ziadny iny toolkit ho tiez nepotrebuje, tak ho bude vediet preskocit. Technicky nie je treba ani freetype ci harfbuzz, ale tieto su dost velke a dolezite na to, aby niekto robil druhu implementaciu).
Mimochodom, COM a Win32 GDI s Win32 controls su dve diametralne odlisne veci. Win32 controls sa daju pouzivat bez COM.... a COM sa da pouzivat bez Win32 UI. Cisty servis, ktory ani nema pristup k desktopu, vie pouzivat COM.
Netvrdim, ze prechod na Qt je chyba, asi by som bol tiez za, ale v pripade vasej firmy ste zjavne riesili iny problem.
No a komentovat C++ kod, ci vyzera hrozne alebo nie.... ono v principe lubovolny kod v C++ vyzera hrozne. Skus si pozriet, ako vyzera vnutri Chrome. Alebo aj spominane Qt, ktore som sebou tiez vlecie pekny kus legacy. Eleganciu Haskellu alebo F# to nikdy nebude mat.