Kontrowersyjne decyzje w środowisku GNOME

Kategoria: Przemyślenia Data publikacji: 7 komentarzy

GNOME jest najważniejszym linuksowym środowiskiem graficznym. Jest najbardziej zaawan­sowane pod względem technologicznym, rozwijane przez ogromną społeczność i wspierane przez rzeszę istotnych w świecie open source korporacji. Niestety, niektóre kontrowersyjne decyzje projektowe twórców GNOME zniechęciły użytkowników i podzieliły, i tak już pofragmentowany, świat desktopowego Linuksa na jeszcze mniejsze frakcje. O co poszło?

Trzecia generacja środowiska GNOME miała premierę w 2011 roku. Wprowadziła ona wiele zmian — być może potrzebnych, ale, wydaje mi się, niewłaściwie przedyskutowanych i zakomunikowanych społeczności. Poniżej wymieniam i wyjaśniam, subiektywnie dobrane, najbardziej kontrowersyjne i niezrozumiane zmiany w GNOME.

Dekoracje po stronie klienta, czyli tzw. CSD

W początkowym etapie rozwoju GNOME 3 twórcy środowiska próbowali w jakiś sposób zaoszczędzić pionową przestrzeń na ekranie. Pozbyto się pasków menu, a ich zawartość przeniesiono do pasków narzędziowych. Następnie wprowadzono specjalną właściwość okien, której włączenie sprawiało, że zmaksymalizowanie okna powodowało ukrycie paska tytułowego. Wadą tego rozwiązania był fakt, że razem z owym paskiem znikał też „krzyżyk” do zamykania okna, toteż użytkownik mógł czuć się przez to zagubiony.

Efektem tych eksperymentów było ostatecznie wprowadzenie tzw. dekoracji po stronie klienta (CSD). Pomijając szczegóły techniczne związane z architekturą klient-serwer serwera X.org, rozwiązanie to polega na wprowadzeniu nowego rodzaju paska narzędziowego, który, prócz standardowych elementów określanych przez aplikację, zawiera także przyciski do maksymalizacji czy zamykania okna określane przez środowisko graficzne. Taki „wzbogacony pasek narzędziowy” na stałe zupełnie zastępuje zwykły pasek z tytułem aplikacji i przyciskami.

Edytor tekstowy GNOME: dawniej (po prawej) i dziś (po lewej).

Pod względem technicznym rozwiązanie wprowadzone do biblioteki GTK — renderującej interfejs w większości linuksowych środowisk — było zaprojektowane kiepsko. Biblioteka GTK za pomocą mechanizmów niezrozumiałych dla niektórych środowisk graficznych wymuszała na nich ukrywanie standardowego paska tytułowego. Początkowo doprowadziło to do wielu przedziwnych błędów takich jak podwójne i źle renderowane obwódki okien.

Z drugiej zaś strony mechanizm CSD sprawił, że linuksowe interfejsy w końcu mogły osiągnąć efekty dotychczas możliwe tylko na konkurencyjnych platformach, na Mac OS czy w Windows. Lubię to komentować w taki sposób: twórcy GNOME zaimplementowali mechanizm CSD najgorzej, jak się dało, ale w praktyce inaczej się nie dało.

Wprowadzenie CSD wpłynęło nie tylko na GNOME, ale także na inne środowiska graficzne uzależnione od technologii i oprogramowania GNOME. Dekoracje po stronie klienta biblioteki GTK psują spójność interfejsu graficznego w środowiskach innych niż GNOME. Jednakże gdyby twórcy GNOME nie zdecydowali się na tę odważną decyzję projektową, niespójności byłoby jeszcze więcej, gdyż programiści poszczególnych aplikacji (szczególnie przeglądarek internetowych) implementowaliby „własne paski tytułowe” w sposób kompletnie odmienny. Oczywiście dekoracje CSD najlepiej prezentują się w GNOME, jednak obecnie większość środowisk graficznych i menadżerów okien potrafi je obsłużyć poprawnie, zaś sam mechanizm CSD został ustabilizowany.

Menu aplikacji, czyli tzw. App Menu

Aplikacje rozwijane w ramach środowiska GNOME korzystały z mechanizmu nazywanego „App Menu”. Było to rozwijane menu zawierające opcje takie jak „Ustawienia”, „Zamknij”, „O programie”, „Pomoc”; innymi słowy: akcje związane z aplikacją samą w sobie, a nie z plikiem otwartym w pojedynczym oknie programu.

Przycisk umożliwiający dostęp do tego menu został umieszczony poza oknem aplikacji, na górnym pasku powłoki środowiska GNOME. Intencja takiego rozmieszczenia była następująca: jako że menu aplikacji zawierało akcje związane z aplikacją, a nie z aktualnie otwartym dokumentem, nie powinno się ono znajdować w oknie aplikacji, lecz poza nim. Jedynie akcje wpływające na otwarty dokument powinny znajdować się w oknie programu.

Podam przykład. Załóżmy, że mamy przed sobą trzy okna edytora tekstowego, a w każdym z nich otwarty zupełnie inny plik. Jeżeli w jednym z okien klikniemy przycisk „Zapisz”, zostanie zapisany tylko plik otwarty w tym właśnie oknie, a pozostałe dokumenty zostaną niezmienione. Natomiast jeśli — za pomocą „App Menu” — dostaniemy się do sekcji ustawień edytora tekstowego i zmienimy jakieś opcje związane z wyglądem bądź zachowaniem programu, zmiany zostaną wprowadzone jednocześnie w każdym z okien. Właśnie dlatego rozwijane „App Menu” zostało umieszczone poza oknem programu.

Menu aplikacji w praktyce.

Rozwiązanie teoretycznie logiczne, jednak w praktyce dla wielu ludzi kompletnie nieintuicyjnie i niezrozumiałe. Nie dość, że podobne menu są niespotykane w innych platformach, to większość oprogramowania nie potrafiła z tego menu korzystać i w praktyce przez większość czasu użytkownik mógł w „App Menu” znaleźć jedynie generowaną automatycznie akcję „Zamknij”.

Z tego dość logicznego, lecz kompletnie nieczytelnego rozwiązania zrezygnowano w ostatnich wersjach środowiska, przenosząc menu programów GNOME do wnętrza okien.

Ikony zasobnika systemowego

Zasobnik systemowy, zwany też przez niektórych obszarem powiadomień lub trayem, jest miejscem na pasku zadań (panelu) najczęściej obok zegarka i daty, w którym system operacyjny i uruchomione programy mogą umieszczać swoje małe ikony. Często z zasobnika korzystają aplikacje działające w tle takie jak komunikatory czy odtwarzacze muzyczne.

O ile większość środowisk wspiera funkcję zasobnika systemowego, próżno szukać jej w GNOME. W starszych wydaniach środowiska zasobnik systemowy schowany był w wysuwanym menu. Obecnie nie ma możliwości korzystania z traya bez instalacji dodatkowych wtyczek. Twórcy GNOME mają kilka dość rozsądnych argumentów przeciwko ikonom zasobnika.

Na Linuksie zasobnik systemowy został zaimplementowany na poziomie serwera grafiki X.org, co sprawia, że nie da się z niego korzystać w serwerze Wayland. Środowisko GNOME wspiera obydwa rozwiązania, dlatego dość sensowne wydaje się unikanie funkcji, które działają poprawnie tylko w jednym z nich.
Na przestrzeni lat powstawały mechanizmy zastępujące przestarzałą technologię takie jak AppIndicator i (K)StatusNotifierItem, jednak GNOME nie wspiera ich bez użycia rozszerzeń.

Zasobnik w XFCE.

Głównym problemem ikon zasobnika systemowego jest ich niespójność i niejednolite przeznaczenie. Niektóre ikony po kliknięciu otwierają menu, inne pokazują okno aplkacji — sposób ich użycia jest niekonsekwentny. Często dochodzi do sytuacji, że ikony statusu systemu (np. poziomu głośności lub połączenia internetowego) mieszają się z ikonami aplikacji uruchomionych w tle. Ikon w zasobniku może nazbierać się dość dużo, a w praktyce użytkownik rozpoznaje i aktywnie używa niewielu z nich.

Według twórców GNOME ikony traya powinny być zastępowane adekwatnymi rozwiązaniami programistycznymi. Regulacja głośności, zarządzanie połączeniem sieciowym czy opcje bluetooth powinny być częścią środowiska graficznego — w GNOME obecne są w menu rozwijanym z górnego paska powłoki.

Menu systemowe powłoki GNOME.

Odtwarzacze muzyczne i komunikatory powinny korzystać z właściwych interfejsów programistycznych, by zintegrować się ze środowiskiem. Gdy aplikacja niewidoczna na ekranie chce poinformować o czymś użytkownika, powinna używać mechanizmu wyskakujących powiadomień środowiska zamiast ikon traya. Może być też po prostu tak, że zamknięcie aplikacji „krzyżykiem” jedynie ukrywa jej okno, a ponowne jego wyświetlenie jest możliwe przez wybranie jej ikony z menu zainstalowanych aplikacji.

Ikony na pulpicie

W środowisku GNOME 3 nie ma ikon na pulpicie i folderu „Pulpit” jako takiego. Przez wiele lat istniała możliwość włączenia domyślnie wyłączonej funkcji ikon pulpitu w aplikacji „Dostrajanie” przeznaczonej do zmiany zaawansowanych ustawień środowiska. Jednakże w ostatnich wersjach środowiska GNOME ten sposób już nie działa — usunięto wsparcie dla tego rozwiązania. Istnieje powszechna opinia, że twórcy GNOME są wrogami ikon na pulpicie.

Co prawda wyświetlanie ikon na pulpicie nie pasuje do minimalistycznej filozofii środowiska GNOME, jednak kompletne usunięcie tej funkcji nie wynikało z chęci wymuszenia na użytkownikach dopasowania się do jedynej słusznej formy obsługi komputera. Za zmianą stały wyłącznie przyczyny technicznie — potrzeba oczyszczenia i rozwoju kodu Nautilusa.

W GNOME 2 wyświetlaniem ikon na pulpicie zajmował się menadżer plików — Nautilus. Tak naprawdę, pod względem technicznym, pulpit był jednym wielkim oknem menadżera plików rozciągniętym na cały ekran, bez paska tytułowego i z ukrytymi paskami narzędziowymi. Początkowo w GNOME 3 mechanizm odpowiedzialny za rysowanie ikon pulpitu był po prostu domyślnie wyłączony, a użytkownik funkcję tę mógł włączyć ręcznie.

Na przestrzeni lat kolejne przebudowy menadżera plików — dodawanie nowych funkcji, optymalizacja, rozwój programu — stawały się coraz trudniejsze ze względu na fakt obecności w kodzie Nautilusa funkcji rysowania ikon na pulpicie. Mechanizm ten do poprawnego umiejscowienia ikon na pulpicie wykorzystywał specyficzne właściwości serwera grafiki X.org, dlatego nie działał natywnie na serwerze Wayland (włączenie ikon pulpitu uruchamiało zagnieżdżony serwer Xwayland).

Ikony na pulpicie jako wtyczka powłoki.

Kod odpowiedzialny za ikony pulpitu był przestarzały i utrudniał rozwój programu — to był główny powód usunięcia tej funkcji. Twórcy środowiska jako zamiennik zaproponowali wtyczkę do powłoki GNOME o nazwie „Desktop icons”. Szkoda tylko, że powstała ona wiele miesięcy po usunięciu funkcji rysowania ikon pulpitu z Nautilusa — może obyłoby się bez awantury.

Komentarze (7)

  1. stała Czytelniczka

    Ehh, żeby ten Linux był zgodny z najnowszym pakietem Adobe, to już dawno bym wywaliła W10. No ale mam inne prace. Nigdy nie podobało mi się Gnome od wersji +3.2. Wolę Xfce.

  2. Tomasz Gąsior

    Ja właśnie jestem w trakcie migracji z XFCE do GNOME. Dziwna decyzja, ale uzasadniona wieloma argumentami, które w przyszłości może ujrzą światło dziennie w postaci kolejnego wpisu. ;)

  3. Tomasz Gąsior

    > Działa ci przycisk touchpada pod Gnome na Xorgu?

    Nie wiem, co masz na myśli pod pojęciem „przycisk touchpada”. Jeżeli chodzi o funkcję „stuknij, by kliknąć”, trzeba sobie ją włączyć w ustawieniach panelu dotykowego.

  4. weron

    Jest włączona w Gnome, ale gdy przełączę się na Xorg stukanie przestaje działać.

  5. Tomasz Gąsior

    Na Waylandzie GNOME używa sterownika libinput, jako jedynego możliwego. Na Xorgu GNOME jest kompatybilne tylko z libinput, ale sam Xorg może być skonfigurowany, aby używać sterownika synaptics. GNOME nie jest kompatybilne z synaptics, co skutkuje brakiem możliwości zmiany ustawień w GUI. Odinstaluj sterownik synaptics, problem ustąpi.

Dodaj komentarz