Tak KDE asi nebude to pravé ořechové pro uživatele awesomewm, ale nějaký tiling WM by mohl. Třeba Sway, což má být Waylandí alternativa k i3. Já aktuálně používám i3 (ano, jsem zatím na X11), k tomu mám na layouty vlastní pyi3l (asi půjde snadno upravit pro Sway).
Ale samozřejmě záleží, co přesně od toho chcete.
Ale tak, WM se taky posouvají, boom je teď Hyprland a Sway má taky svoji popularitu. Já se o WM nezajímám, takže nemám o nich přehled, jen z doslechu, ale věřím, že poptávka po Wayland-based řešení tam bude taky.
Pokud ne, tak ať se toho někdo ujme. Vždy mám pocit, že na Root.cz je hejno velmi chytrých lidí. Proč tedy nezačne někdo psát "tu konkrétní" správnou věc, která nemá dardu chyb, chybných přístupů a všeho, co Root.cz pisatel odsoudí na pokraji hrdelního zločinu?
Když ne to, tak Merge Request nebo issue u existujícího projektu zvládne taky každý.
Vidím to velmi podobně. Mám svojí představu o práci s vícero monitory - chci sadu virtualních ploch které nejsou vázané na monitory, a libovolnou plochu můžu rychle a jednoduše zobrazit na jakémkoliv monitoru. Vím jen o dvou okenních prostředích (na jakékoliv platformě) které tohle zvládnou - Xmonad a Awesome.
Co jsem zkoumal Waylandí kompozitory, tak většina jsou buď DE mološi, nebo (polo)mrtvé hračky. Žádný nenabízí ani zlomek konfigurovatelnosti X11 WM jako Awesome, Xmonad, nebo FVWM. A to nemluvě o tom, že bych musel svoji poměrně komplikovanou konfiguraci kompletně přepisovat do něčeho nového aniž bych tím cokoliv získal
Já ale nechci přesouvat plochy, chci aby se to chovalo tak že plochy nejsou vůbec přivázané k monitorům (pokud zrovna nejsou někde zobrazeny). Už je to teda dost dlouho co jsem to zkoumal, a nevylučuji že mi něco uniklo, ale získal jsem dojem že na to i3 (ani žádný jiný WM s výjimkou výše jmenovaných) není dost flexibilní.
Ono teď přes dva roky se jede na awesome-git po jednotlivých CI. Elv13 tam chce teď po půl roce dotlačit poměrně velkou věc, původně se plánoval release na Vánoce, ale bude to spíš až v Q1/24. Ten původní release někteří uživatelé využívají, ale kvůli API, nové dokumentaci a řízení pomocí událostí je lepší opravdu být na CI procesu.