Poprzedni artykuł o Unity napisałem dość chaotycznie, pod wpływem narastającej irytacji. Wczoraj przypadkiem skasowałem sobie wszystkie ustawienia konfiguracyjne Compiza i kluczowy problem (okna wędrujące po desktopach) zniknął – wygląda więc na to, że był efektem jakiejś kombinacji pluginów i ich ustawień (a test ciągania między desktopami będę musiał powtarzać ilekroć cokolwiek ruszę w Compiz Config Settings Managerze).
Dzisiaj spróbuję spokojniej napisać co mi się w Unity podoba, a co mnie razi.
Co mi się podoba w Unity
Kluczowym powodem, dla którego próbuję się przyzwyczaić do Unity a nie do Gnome3 i dla którego nie zdecydowałem się na przesiadkę na KDE czy XFCE jest – o dziwo – kompatybilność wstecz. A dokładniej: używanie Compiza. Bo Compiz to nie tylko trochę graficznego bajeru ale przede wszystkim sporo bardzo użytecznych skrótów klawiszowych związanych z zarządzaniem oknami (niektórych dostępnych domyślnie, innych możliwych do zdefiniowania) – o których pisałem tutaj oraz tutaj. Przywykłem do nich bardzo i trudno mi sobie wyobrazić pracę bez Expo czy bez rzucania oknami po siatce.
Pozytywnie oceniam również kluczową innowację, tj. uruchamianie programów przez (krótkie) pacnięcie klawisza Win i wpisanie fragmentu nazwy (a także fakt, że rozwiązanie to uczy się i podsuwa w pierwszej kolejności rzeczy jakich już używałem).
Nie jest to dla mnie rewolucja – od dawna używałem Gnome Do a potem Synapse (Synapse jest nieco uboższe funkcjonalnie ale znacznie stabilniejsze, ponadto wprowadza elementy preferowania używanych aplikacji czy plików) – ale doceniam próbę przekonania do tej formy masowych użytkowników.
Zarazem jednak wolę podejście Do/Synapse, w którym wpisuję fragment nazwy, a program podsuwa mi wszelkie pasujące sugestie – niezależnie od tego, czy jest to nazwa programu, pliku, kontaktu, komenda shellowa z parametrami, czy coś jeszcze innego – od podejścia Unity, w którym muszę najpierw wybrać o co mi chodzi a dopiero potem szukać. Z Synapse mogę wcisnąć Win-Spacja (mój skrót do jego uruchamiania), wpisać
sudo apt-get update
i wybraćRun in Terminal
, panel Unity na takie sztuczki nie pozwoli (bardziej praktyczny wymiar ma to zawsze, gdy chcę odpalić po nazwie program nie mający wpisu w menu, Synapse czy Do zaproponuje odpalenie go jako komendy, Unity – nie.
Niezależnie od powyższych uwag: launcher Unity jest ogromnym postępem w stosunku do tradycyjnego menu Applications/Places.
Początkowo miałem opory związane z … utratą klawisza Win – jego kombinacje dotychczas bardzo lubiłem mapować na różne akcje Compiza a także na skróty w aplikacjach, właściwie nic go nie używało – ale przyznaję, że wybór dokonany w Unity jest logiczny i naturalny i po paru dniach używania uderzanie Win wchodzi w krew.
Mieszane uczucia
Mieszane uczucia mam w stosunku do lewego paska (czyli efektu dłuższego wciśnięcia klawisza Win). Możliwość szybkiego wyboru klawiszem (przytrzymuję Win i wybieram numerek odpowiedniej ikonki) niewidocznego czy zminimalizowanego okna to rzecz bardzo sympatyczna.
Z niezadowoleniem odbieram natomiast fakt, że powyższa kombinacja czasem przywołuje istniejące okno a czasem (gdy takowe nie działa) uruchamia nowy program. Zdecydowanie wolałbym mieć pełną kontrolę nad tym, czy uruchamiam coś nowego, czy przywołuję coś, co już działa.
A już zupełnie nie podoba mi się wymuszone grupowanie. Uruchomiłem cztery terminale? Win-(powiedzmy)-3 przywoła … któryś. Mogę potem naciskać Alt-` by wybrać właściwy ale to zestawienie kombinacji jest antyergonomiczne (spróbujcie szybko wcisnąć Win-3 a potem LewyAlt-`…).
Obie powyższe cechy składają się na efekt: pasek Unity nie pełni roli informacyjnej o tym ile i jakich okien tej czy innej aplikacji działa ani też nie pozwala łatwo znaleźć i odtworzyć konkretnego okna.
Nie podoba mi się – ideowo
Powyższe to objawy pewnej szerszej idei: Unity (Gnome3 zresztą też) orientuje się na aplikacje a nie na okna. Mam myśleć o tym, że mam uruchomionego Firefoksa, Emacsa i terminal – a fakt, że chciałbym mieć parę okien przeglądarki czy kilka terminali, staje się w jakiejś mierze anomalią.
Nie zgadzam się z tą koncepcją. Pasuje mi ona do padów, netbooków czy telefonów ale nie do pełnokrwistego desktopu. Terminal na którym odpalam testową wersję programu ma dużo więcej wspólnego z działającym obok oknem edytora niż z umieszczonym na innym desktopie terminalem w którym po ssh robię update na zdalnej maszynie. Okno przeglądarki z którego ściągam zapisy partii turniejowych jest logicznie związane z oknem ChessAssistanta w którym je przeglądam, a nie z innym oknem przeglądarki w którym mam otwartego gmaila. Itp itd. Grupowanie okien ma sens ale … dlaczego akurat na podstawie programu? Wyobrażam sobie, że lepiej mogłoby działać grupowanie na zasadzie bliskości położenia albo faktu, że zwykle między danymi dwoma oknami przełączam focus.
Druga ideowa sprawa jaka mi nie odpowiada, to zmniejszanie możliwości konfiguracyjnych. Gdzie tradycyjne panele Gnome2 czy KDE pozwalały swobodnie dodawać/usuwać elementy, pasek Unity jest niemal niekonfigurowalny. Gdzie można było sobie odklikać całą masę charakterystyk wyglądu i zachowania desktopu, teraz okna ustawień ograniczają się do wyboru obrazka tła i nazwy tematu. Dobrze chociaż, że jest CCSM, Gnome3 nie ma i tego (acz używanie CCSM staje się ryzykowne, jak sam się przekonałem, nie wszystkie pluginy i nie wszystkie ich ustawienia dobrze współgrają z Unity).
Trzecia rzecz to postępujące marginalizowanie trybu focus follow mouse i możliwości pracy z częściowo przykrytymi oknami. Mam do tego osobisty zadawniony sentyment sięgający czasów stacji roboczej Digital Unixa, bardzo często zdarza mi się np. pisać w terminalu, którego większa część jest zasłonięta oknem edytora wyświetlającego stronę mana albo przeglądarki z dokumentacją.
W Unity … hmm, jak ja właściwie włączyłem focus follow mouse? W
standardowych ustawieniach nie ma, o ile pamiętam ręcznie edytowałem
rejestr (gconf-editor
i apps → metacity → general
a tam
focus_mode
).
Wreszcie – nie cierpię pomysłu przenoszenia menu do górnego panelu ekranu. W trybie focus follow mouse praktycznie pozbawia mnie to menu w oknach które leżą nieco dalej od lewego górnego rogu (nim dotrę myszą do menu zwykle łapię kontekst innego okna i … menu jest już inne), do tego burzy koordynację aplikacji z jej menu, nawet tę koncepcyjną. Znowu: jest to niezły pomysł na tablecie/netbooku gdzie z reguły okna są zmaksymalizowane ale niespecjalnie udany na laptopie a zupełnie nonsensowny na dużym desktopowym ekranie.
Przenoszenie menu można na szczęście wyłączyć, choć jest to dobrze ukryte. Za aktywację tej techniki odpowiadają pliki
/etc/X11/Xsession.d/80appmenu
oraz/etc/X11/Xsession.d/80appmenu-gtk3
. a dokładniej, ustawiana w nich zmienna środowiskowaexport UBUNTU_MENUPROXY="libappmenu.so"
Pozbycie się jej rozwiązuje problem. Ja zrobiłem to dopisując na końcu obu powyższych plików
export UBUNTU_MENUPROXY=0
(celowo tak, by dostawać pytania przy ewentualnych upgrade) ale można też je po prostu usunąć, zrobić plik o większym numerku (np.
/etc/X11/Xsession.d/81disableappmenu
) a bez dostępu do roota kombinować z~/.xsession
.
Nie podoba mi się – w drobiazgach
Irytuje drastyczne obcięcie funkcjonalności górnego paska. Lewa część, w której miałem zwyczaj umieszczać ikonki bardzo często uruchamianych programów, obecnie jest po prostu niedostępna (zarezerwowana na nieszczęsne menu aplikacji). Znikła także możliwość dodania apleciku przez prawy klik i Add to Panel – parę istotnych dla mnie rzeczy (min. monitor zasobów) udało mi się po różnych PPA poznajdować ale trzeba je uruchamiać ręcznie a mechanizm wygląda na przeznaczony do eliminacji.
Wyrżnięto API systraya, co sprawia problem z programami które miały zwyczaj minimalizować się do paska, które bądź utraciły tę zdolność, bądź po minimalizacji nie pozwalają się odtworzyć. Miałem zwyczaj minimalizować do paska KeePassX, Shuttera i Zima, dziś nie jest to możliwe dla żadnego z nich. Najbardziej brakuje mi robienia screenshotów przez prawy klik na ikonce Shuttera w trayu ale też prostej wyróżnionej jednoklikowej dostępności tych często potrzebnych na chwilę programów (w lewym pasku Unity czasem są, czasem ich nie ma, a gdy są, to w coraz to innym miejscu).
Denerwuje mnie pomysł, by ilekroć zbliżę przeciągane okno do góry ekranu, maksymalizowało się ono. I nie widzę sensu tego gestu – kliknięcie ikonki maksymalizuj jest prostsze niż ciąganie za belkę, skoro zdecydowałem się ciągnąć, to widać miałem coś innego na myśli.
Można to jakoś wyłączyć przy pomocy CCSM ale w tej chwili nie pamiętam, gdzie znajduje się odpowiednia opcja.
Mam też problemy z przyzwyczajeniem się do faktu, że przyciski (od)maksymalizowania czy zamykania okna są po jego maksymalizacji przenoszone do górnego panelu. Ideę tu rozumiem – górny pasek jest widoczny a nie zabiera miejsca – ale powstaje dziwny efekt w którym przed maksymalizacją okna te przyciski są z prawej strony a po maksymalizacji z lewej i … ręka biegnie gdzie indziej.
Brakuje mi trochę możliwości robienia paneli pomocniczych i małego widoku wszystkich desktopów w dolnym pasku.
Tęsknię za klarownym podziałem w którym Alt-Tab skakało między oknami na bieżącym desktopie a Win-Tab między wszystkimi (rzecz prawdopodobnie do odzyskania przy pomocy CCSM ale obecnie ruszanie skrótów zawierających klawisz Win jest nieco ryzykowne, potrafią być raportowane jako konflikty).
Wreszcie – łatwo trafiam na takie czy inne tajemnicze błędy, ten
opisywany ostatnio nie był bynajmniej jedyny. Miewałem dni, gdy compiz
padał co kilkadziesiąt minut. Bywało, że lewa część ekranu (ta spod
paska) nie odświeżała się. Bywały kłopoty z rozmieszczaniem okien po
desktopach (o tym pisałem poprzednio). Od paru dni zdarza mi się, że
jakaś aplikacja nagle zaczyna używać 100% procesora przy jednoczesnym
podwyższonym użyciu CPU przez /usr/bin/X
i chyba miewa to związek
z jej wcześniejszym przeniesieniem między desktopami. Itd itp… Każdy
konkretny problem zwykle po pewnym czasie znika ale zastępują go
kolejne. Pewne bóle nowości są zrozumiałe ale napotykam na nie jakoś
niepokojąco często.
Uzupełnienia
Do artykułu dostałem różnymi drogami trochę uwag, poniżej wynotowuję co ważniejsze konkretne wskazówki.
\1. Dla KeepassX działa workaround: w pliku /etc/xdg/sni-qt.conf
należy dopisać keepassx=1
– u mnie plik wygląda potem tak:
[need-activate-action]
clementine=1
mumble=1
skype=1
speedcrunch=1
keepassx=1
Później można ponownie włączyć opcję minimalizacji do systraya. Odtwarzanie zminimalizowanego okna jest mniej wygodne – nie działa dwuklik, lewy klik na ikonce w trayu otwiera menu w którym trzeba wybrać opcję Activate – no ale ogólnie działa.
\2. Ciekawym uzupełnieniem dla Expo (domyślnie Win-S) jest Spread Mode otwierane przez Win-W – widok miniaturek wszystkich okien.
Mechanizm ten jest dostępny także w compizie przed Unity, w Ubuntu 10.04 można
go włączyć w CCSM wchodząc do Window Management → Scale
i mapując na jakiś klawisz - np. Win-w
-
akcję Initiate Window Picker For All Windows
.
\3. W czasie Alt-Tab można nacisnąć Alt-↓ albo po prostu chwilę zaczekać (ciągle trzymając wciśnięty Alt).
Efektem jest rozwinięcie się miniaturek wszystkich okien aktualnie wybranej aplikacji.
Między tymi oknami poruszamy się standardowo przy pomocy Tab, a powrót do głównej listy następuje po Alt-↑.
\4. Najlepszą dokumentacją skrótów klawiszowych Unity jest ten oto artykuł na askubuntu.com. A innym miejscem gdzie można sprawdzić na jaki klawisz czy gest coś jest zamapowane jest … CCSM, który nie tylko pozwala je zmieniać ale także w dość znośnej formie prezentuje.
\5. Automatyczne maksymalizowanie okna po dotknięciu górnego brzegu można wyłączyć przy pomocy CCSM, jest to jeden z gestów w ramach lubianego przeze mnie pluginu Grid. By się tego pozbyć, po prostu przestawiamy w zakładce Edges opcję Top Edge z Maximize na None.
\6. Przyciski zamykania, maksymalizacji czy minimalizacji okna mogą
być umieszczone z lewej strony (co likwiduje rozbieżność między
normalnym a zmaksymalizowanym) – i domyślnie są (zależy to chyba od skórki?).
Aby to skorygować należy uruchomić gconf-editor
, rozwinąć
apps → metacity → general
i zmienić wartość opcji button_layout
na
close,minimize,maximize:menu
(dwukropek rozdziela część lewą od prawej).
\7. Unity wprowadza też nową formę prezentacji scrollbara, o której nie wspominałem, bo pozbyłem się jej natychmiast po upgrade przy pomocy
sudo apt-get remove overlay-scrollbar \
liboverlay-scrollbar3-0.2-0 liboverlay-scrollbar-0.2-0
Powyższą operację przeprowadziłem w ramach tropienia przyczyn problemów z wydajnością X-ów (wygooglowałem trochę sugestii obciążających nowy scrollbar odpowiedzialnością za takowe), ostatecznie hipoteza okazała się niesłuszna ale na razie nie zdecydowałem się na reaktywację, tradycyjny scrollbar nie jest zły.
Skoro o tym wspomniałem: bezpośrednio po upgrade do 11.10 moje X-y często się zamrażały na sekundę czy parę, miałem też problemy z prezentacją paska Unity (wyświetlał się bardzo powoli). Pomogła mi zmiana wersji drivera Nvidii - w programiku Additional Drivers (tj.
jockey-gtk
) przeszedłem z version current na post-release updates i (po przebudowaniu modułów jądra i restarcie) kłopoty się skończyły.