Vlákno názorů k článku Kim Dotcom bude vydán do USA, herní engine Godot s podporou Waylandu od Ladis - > Dále KWin dostal podporu Wayland protokolu alpha-modifikátoru,...
-
Moc "pěkný" kód a podle diskuze se to kompiluje věčnost. Naštěstí v naší firmě jsme se zbavili COM (přešli jsme na Qt).
18. 8. 2024, 23:51 editováno autorem komentáře
-
Qt predsa nie je systemovy toolkit na ziadnom systeme a pri nom treba portovat z jednej major verzie na druhu. Ci to uz nie je problem?
(Ako ja osobne s tym nemam problem, Qt je pekny toolkit a vyvoj ide smerom, ze aplikacie na vsetkych systemoch si ponesu toolkit so sebou, ala flatpak. Ale tvoj argument bol iny.)
-
Naše firma se zbavila problémů s COM přechodem na Qt. A ten je systémový na Linux/KDE, ale to berme jako detail. Základem sdělení bylo, že ten C++ kód s WinUI vypadá hrozně a přináší problémy. Věřím, že na tom žádná větší C++ app nevznikne.
PS: Zajímalo by mě, zda to používá nativní vzhled prvků z WinAPI, nebo si je kreslí ručně. Pro dřívější WPF "jedenáctková" grafika nevznikla, ani tmavý režim pro desítky.
19. 8. 2024, 00:03 editováno autorem komentáře
-
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.
-
Jo, a WinUI si kresli vlastne widgety. Ono aj samotne Win32 widgety maju rozdielny vzhlad, v zavislosti od verzie windows (a manifestu aplikacie, ze ktoru verziu pouzit), takze nieco ako "standardne windows controls" uz tiez davno neexistuje.
Samotny theming nie je gro prace na widgetoch. Ale a11y, rtl rezim, atd, to dokaze byt peklo.
19. 8. 2024, 00:36 editováno autorem komentáře
-
Jen doplním:
> Ono aj samotne Win32 widgety maju rozdielny vzhlad, v zavislosti od verzie windows (a manifestu aplikacie, ze ktoru verziu pouzit), takze nieco ako "standardne windows controls" uz tiez davno neexistuje.
Právě že s manifestem od XPček mám v každé budoucí verzi Windows nativní vzhled. Což u těch ručně kreslených není (to je i případ Qt - když vyjde nová verze Windows nebo macOS, musí se počkat na novou verzi knihovny a aktualizovat aplikaci).
> Z danej definicie vyplyva, ze Qt nie je a nebude systemovym toolkitom na ziadnom linuxe.
Co ty postavené na KDE?
> 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
Wayland a X11 nejsou GUI toolkit. Ale jnak je dobré, že KWin umí ten blur. A až za pár let ho bude umět i Wayland protokol, tak to doplní.
> 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
Nicméně ten WinUI 3 ho potřebuje pro použití v C++.
19. 8. 2024, 00:42 editováno autorem komentáře
-
> Co ty postavené na KDE?
Este raz:
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.
Ovlada Qt jedine/privatne API ku kompozitoru a pokial chce nejaky iny toolkit nieco riesit, musi linkovat ku Qt? Nie? Tak ani Qt nie je systemovy tookit.
To, ze existuju distribucie, ktore maju ako default desktop KDE na tom nic nemeni.
> Wayland a X11 nejsou GUI toolkit.
To je pointa. Wayland-protocols a x11proto su API k display serveru. Na inych systemoch su tieto API privatne. Na Linuxe nie, preto moze hocikto vytvorit toolkit (alebo aplikaciu), ktory sa cez socket bavi s display serverom.
Je to vyhoda aj nevyhoda zaroven. Nevyhoda sa prejavila napriklad so zavedenim HiDPI - ine systemy to pridali do svojich toolkitov na strane aplikacii, ale to na Linuxe nebolo mozne, pretoze nic, co by sa povinne linkovalo do aplikacie neexistuje; kazdy si cez socket posiela co chce.
-
Ano, X11/Wayland/kompozitor nejsou GUI toolkit. V Linuxu je to takto rozdělené. Ale pokud aplikace používala běžný GUI toolkit (Gtk, Qt, ...), tak např. ta podpora HiDPI, a dokonce i MultiDPI, byla v základu. 10 let před Waylandem jsem v tehdy majoritním Ubuntu (výchozí prostředí Unity) mohl přetáhnout Gtk/Qt aplikaci na druhý monitor a on jí změnil meřítko, pokud ten monitor měl jiné. Akorát Firefox dostal patch, protože ten není postavený na Gtk (i když ho využívá/l na kreslení UI prvků). Fungovalo to jednoduše, skriptováním X11 (podobně jako si můžu třeba nastavit jinou rychlost kolečka myši pro jednotlivé aplikace oddeleně - dřív když Chrome vzdoroval nastavení Linuxu).
19. 8. 2024, 01:01 editováno autorem komentáře
-
> V Linuxu je to takto rozdělené.
Ono je to tak rozdelene vsade. Vo windows je to dwm, na macos quartz compositor. Akurat tam k tomu nie je verejne api (uz sa opakujem).
> Ale pokud aplikace používala běžný GUI toolkit (Gtk, Qt, ...), tak např. ta podpora HiDPI, a dokonce i MultiDPI, byla v základu.
Nie, nebola. X11 mal pokus o definiciu dpi displeja, ale vacsina aplikacii s tym nevedela pracovat, maximalne menit koeficient medzi pt a px fontov. Ostatne assety zobrazovali tak, ako boli (t.j. povecsinou 96 dpi), cim boli okna viac-menej rozbite; ani layout manager v niektorych toolkitoch to nevedel zachranit.
> mohl přetáhnout Gtk/Qt aplikaci na druhý monitor a on jí změnil meřítko, pokud ten monitor měl jiné
Az na taky detail, ze v Xinerama a xrandr vsetky screeny museli mat rovnake dpi (a rovnaku farebnu hlbku). Xinerama bol totiz hack, ktory z jednotlivych monitorov poskladal jeden, rozlozeny cez viacero monitorov ("screen" v x11 hantyrke), ktory mohol mat diery, ak mali rozlicne rozlisenia.
Rozlicne dpi a farebne hlbky mohli mat displeje ("display" v x11 hantyrke), ale medzi jednotlivymi displejmi sa nedali pretahovat okna. Aplikacia musela zrusit a pozatvarat vsetky zdroje na jednom displeji a znovu ich povytvrat na inom. Historicky jedina aplikacia, ktora toho bola schopna, bol Xemacs.
-
Však jsem napsal ten trik X11, jak to fungovalo. A ano, neumělo to samotné X11, ale desktopové prostředí nad ním (tehdy Unity v Ubuntu). Koneckonců Wayland není o nic lepší - půlku práce za něj musí/ela dělat desktopová prostředí.
Mimochodem používá se to dodnes. Např. Chrome/ium ve Fedoře, pokud tedy už teď není Wayland verze, tak předtím byl X11 verze a dostával správné info o DPI, aby nebyl rozmazaný.
