Od czasu gdy chwaliłem wygodę korzystania z Compiza, trochę się zmieniło.
Compiz na gorsze. Autorzy uznali, że (bardzo dla mnie wygodna) konwencja rzucania okien po siatce skrótami klawiszowymi jest zbyt konfudująca dla części użytkowników – i drastycznie ją ograniczyli (działa tylko rzut do połówek i ćwiartek, nie ma efektu wyboru kolejnych rozmiarów przez powtarzanie naciśnięć klawisza).
Na lepsze zmienił się mój monitor w pracy. Mam szerszy, na którym naturalne jest rozmieszczenie obok siebie trzech okien edytora.
Przez mniej więcej rok korzystałem z Awesome. Kilka miesięcy temu je, z pewną ulgą, porzuciłem ale doświadczenie było ciekawe i parę spraw zanotuję.
Cel zabawy
Najpierw krótko przypomnę o co chodzi. Używając Awesome (a także w XMonad i paru mniej znanych kafelkowych menedżerów okien) nie ustawiam rozmiaru okienek ani ich położenia, nie ciągnę myszą, nie łapię za belkę tytułu ani za róg. Zamiast tego, menedżer okien sam rozmieszcza okienka, uwzględniając ich aktualną ilość i wybrany układ. Zatem, po otwarciu dwóch ramek Emacsa i terminala uzyskuję automatycznie - bez żadnego myszowania - mój ulubiony zestaw:
Zrzuty ekranowe prezentowane w tym artykule robiłem na laptopie (trochę dlatego, że miałem go akurat pod ręką, ale też aby były czytelniejsze jako screenshoty). Oczywiście układ 3x1 czy 3x2 prawdziwy sens zyskuje na szerokim panoramicznym monitorze.
Gdy otworzę jeszcze przeglądarkę, okienka zmieniają pozycję tak, by nadal wszystkie były widoczne.
(powyższe przykłady robione przy układzie termfair, z którego korzystałem najczęściej)
Czemu (jednak) nie
Model automatycznego rozmieszczania okien jest w wielu wypadkach wygodny ale czasem strasznie irytujący. Cieszy, że dwa okna Emacsa i jedno Firefoksa ładnie i bez bólu nadgarstka układały się obok siebie. Fatalnie, że nie było sposobu, by okazyjnie to ostatnie odrobinę poszerzyć (i zobaczyć ten przycisk umieszczony w prawym górnym rogu przez designera oczekującego szerokości ≥ 960).
Możliwość zmiany układu okien na inny teoretycznie była użyteczna, w praktyce jednak jej efekty zwykle stanowiły dla mnie wstrząs. Wciśnięcie jednego klawisza zmieniało:
w:
po czym dłuższą chwilę musiałem się ponownie orientować w zawartości ekranu.
Trochę łatwiej absorbowałem efekty Win-Enter (zmiana głównego okna):
acz i one bywały zaskakujące (które okno wyskoczy…). Najgorzej zaś zaskakiwały konsekwencje zmiany ilości okien master, ilości kolumn czy proporcji, które przenosiły się między układami totalnie zmieniając przy tym znaczenie (zmiana ilości kolumn w termfair wpływała na organizację tileleft itp). Ostatecznie: nigdy nie zyskałem tego instynktownego poczucia wiem, co się stanie, jeśli nie zaskakiwał mnie układ, to kolejność okienek.
Niektórych standardowych układów wręcz nie rozumiałem, nie udało mi się wymyślić przypadku, w którym byłyby użyteczne. Oczywiście, wszelkie problemy układowe mógłbym rozwiązać pisząc własne – ale to byłaby już dość niewdzięczna i kłopotliwa praca.
Problem całkowitego braku podpowiedzi, przypominajek, dymków itp rozwiązałem sam, o czym niżej.
Już na starcie używania okazało się, że rzeczy, które normalnie są oczywiste (jak choćby prosty monitorek obciążenia systemu, aplecik głośności czy kalendarz/zegar) muszę oprogramowywać. Wiele z nich dało się znaleźć w formie snippetów do dogodnego skopiowania ale wymagały pewnego wysiłku, by zadziałały.
Nie wszystkie aplikacje radziły sobie w kafelkowym środowisku. Parę Javowych programów straciło zdolność używania myszy, wiele źle reagowało na wymuszony rozmiar (czy to źle się rysując, czy to nie dając scrollbara ani żadnej innej możliwości zajrzenia do części schowanej za prawym brzegiem, czy to przynajmniej uparcie zaokrąglając swój rozmiar i nie respektując w pełni nakazów menedżera).
Wreszcie, Awesome jest zwyczajnie brzydkie. Płaskie, nijakie, przypominające interfejsy, które używałem w latach 90-ych. Kolor, cieniowanie, dyskretne podświetlenie tu i tam, drobne animacje – to nie są bezużyteczne gadżety. Dają zauważalnie inne odczucia przy pracy.
Kroplą, która ostatecznie przeważyła, były głębokie, niekompatybilne zmiany między Awesome 3.4 a Awesome 3.5. Okazało się, że aby dokonać migracji, praktycznie całe moje wypieszczone środowisko musiałbym oprogramować od nowa. Autorzy zlikwidowali całą serię API wszechobecnych w dodatkach, pluginach czy popularnych snippetach.
Parę pozytywów
Awesome jest faktycznie szybkie i sprawne. Niemal natychmiastowa prezentacja desktopu po zalogowaniu, błyskawiczny restart po zmianach konfiguracji, faktycznie sprawne zarządzanie oknami.
Model, w którym żadne okno nie jest przykryte, faktycznie coś w sobie ma.
Całkiem podobało mi się też oprogramowywanie desktopu w prostym języku. Kilka skupionych w jednym miejscu plików które mogłem wygodnie wersjonować, grepować, edytować i synchronizować to coś dużo poręczniejszego niż rozproszone w mnóstwie miejsc rejestry, [dgk]confy i chmary ustawień edytowalnych wyłącznie myszą.
Sam język Lua, którego nauczyłem się trochę przy tej okazji, również okazał się całkiem przyjemny.
local mod_translate = {
[modkey] = "⊞",
Shift = "⇧",
Control = "Ctrl",
Mod1 = "Alt",
}
-- Creates textual description of the key
local function format_key_label(key)
local sym = key.key or key.keysym
sym = key_translate[sym] or sym
if not key.modifiers or #key.modifiers == 0 then return sym end
local result = ""
for _, mod in ipairs(key.modifiers) do
mod = mod_translate[mod] or mod
result = result .. mod .. " + "
end
return result .. sym
end
Parę moich autorskich rozwiązań
Wszystko o czym piszę poniżej można sobie wyzbierać z tego repozytorium, w którym odłożyłem końcową konfigurację mojego desktopu. Sformułowanie autorskie jest pewną przesadą, intensywnie korzystałem z rozmaitych fragmentów czy przykładów odszukiwanych w sieci szerokiej.
Uważam, że programy powinny pomagać użytkownikom, dlatego zaimplementowałem sobie pomoc dotyczącą skrótów klawiszowych (wyświetlaną po wciśnięciu Win-F1):
a także przełączania między desktopami (tagami w slangu Awesome):
Uczucie zagubienia trochę zmniejszała mi informacja na jaki layout zmieniłem i jakie ma on parametry wyświetlana automatycznie po każdej zmianie:
Udało mi się też wypracować podział na pliki, w którym zamiast gigantycznego bloba cała konfiguracja miała dość logiczną strukturę.
Ostatnim elementem był skrypt perlowy, który
-
instalował systemowo pliki
desktop
isession
dzięki którym na oknie logowania miałem do dyspozycjiAwesome GNOME
, a startująca po takiej aktywacji sesja odpalała standardowe usługi GNOME (takie jak choćbykeyring
czypulseaudio
) -
korygował systemowe pliku autostartu rozmaitych aplikacji graficznych (pliki w
/etc/xdg/autostart
), dodając im dyrektywy nakazujące działanie - albo nie działanie - pod Awesome (większość tych plików zawierała dyrektywy sensownie ustalające które mają startować pod Gnome, które pod KDE, które pod XFCE – dla Awesome trzeba było odpowiednie zapiski dodać).
Podsumowanie
Przygoda z Awesome nie porwała mnie ale uważam ją za interesującą. Roczna praca z tym systemem zmieniła sporo moich przyzwyczajeń (np. zauważalnie rzadziej sięgam po mysz), poznałem potencjalnie przydatny prosty język programowania (Lua jest dość popularnym językiem zanurzanym jako język rozszerzeń, od gier po LuaTeX), zacząłem bardziej programistycznie patrzeć na zarządzanie desktopem. Dowiedziałem się też troszkę o szczegółach działania menedżerów okien. Dlatego całkiem tego typu doświadczenie polecam (jeśli nie z Awesome to z XMonad, co byłoby realną szkołą Haskella).
Ostrzeżenie: moim zdaniem nie ma większego sensu próba ich używania na zasadzie gotowca. Wdrożenie takiego desktopu to niewielki, osobisty projekt programistyczny, w którym wygodne, dostosowane do własnych potrzeb, środowisko trzeba sobie oprogramować. Sam desktop zapewnia, że programy te będą niedługie i nietrudne do napisania (a ich napisanie nie musi być bardziej pracochłonne niż wyklikiwanie stert ustawień w bardziej graficznych środowiskach) ale odpowiedni wysiłek trzeba włożyć.
A o desktopie, którego używam obecnie (na razie ku dość sporemu zadowoleniu) napiszę za czas jakiś…