Czy środowisk graficznych jest za dużo?

"Róg obfitości", w świecie linuksowym to określenie nabiera szczególnego znaczenia, zważywszy na mnogość różnych projektów, które w zasadzie robią to samo, czasami w nieznacznie zmienionej formie. Pytanie tylko, czy czasami ów wysyp rożnych przedsięwzięć nie przybiera rozmiarów absurdu.

Siła w różnorodności

Właściwie odkąd pamiętam zawsze pojawiały się narzekania na zbyt dużą ilość dystrybucji, ale od jakiegoś czasu do tej listy dołączyły środowiska graficzne. Jednak co takiego się zmieniło w ciągu ostatnich 2 (?) lat, wszakże zawsze dało się wskazać kilka środowisk. KDE i GNOME były oczywistym wyborem, w tle przewijały się XFCE i LXDE. Niestety ostatnimi czasy nastąpił mały zgrzyt, który spowodował cudowne rozmnożenie....

Unity vs GNOME Shell

Cytat powyżej to wypowiedź Jono Bacona z października 2010 roku. Co by nie mówić, wiele osób łyknęło tę śpiewkę jak pelikan rybę. Jakby nie patrzeć Ubuntu zawsze miało dobry PR i osobliwe poczucie humoru. O przyczynach rozpadu GNOME już pisałem dlatego nie będę się powtarzał. Niestety podział w sercu jednego z kluczowych środowisk graficznych spowodował polaryzację nastrojów. Kiedyś wojny toczyli użytkownicy GNOME i KDE, teraz Unity i GNOME Shell, wystarczy poczytać komentarze, choćby tutaj. A przecież są to tylko inne powłoki w ramach jednego środowiska, no cóż użytkownicy zdają się uważać inaczej.

Plankton środowiskowy

Słyszał ktoś o Mate, Cinnamonie czy Consort. Nie, nie zamierzam opisywać każdego z osobna, bo wszystkie te  "środowiska" robią to samo, próbują naśladować GNOME 2 w mniej lub bardziej nieudolny sposób. Nikt nie odmawia prawa do forkowania, ale litości to już robi się nudne, tym bardziej, że na horyzoncie pojawia się...

GNOME 3.8 z classic mode

Surprise, surprise, to co widzimy powyżej właśnie przekreśla jakiekolwiek racjonalne powody istnienia wymienionych wcześniej podróbek GNOME 2. Bo oto stała się rzecz cudowna, deweloperzy GNOME, który cierpią na chroniczny syndrom NIH, zeszli ze swojego wysokiego konia i usłyszawszy lamenty użytkowników przygotowali specjalna wersję klasycznego pulpitu. Wszystko jak najbardziej koszerne, korzystające z niesamowitych możliwości rozszerzeń, a co najważniejsze pobłogosławione przez deweloperów Red Hata. Pytanie tylko czy nie jest już za późno, tym bardziej, że niektóre forki jak np. Cinnamon trzymają się całkiem nieźle. Jednak i tu deweloperzy czerwonego kapelusznika mają wszystkich w garści, a to ze względu na aplikacje.

Kto ma programy ten ma władzę

Panel i kilka opcji konfiguracyjnych na krzyż nie czyni jeszcze nowego środowiska, równie ważne są aplikacje. W tym przypadku Red Hat trzyma wszystkich na muszce i robi co chce nie oglądając się na innych. Przekonali się o tym deweloperzy rożnych forków, w tym Cinnamona, którzy określili Nautilusa 3.6 jako katastrofę :

Deweloperzy Minta mówią tu o usuwaniu opcji, które są ich zdaniem niezbędne. Listę zmian można sobie obejrzeć na stronach GNOME. Wystarczy rzut okiem na te małe rewolucje w wyglądzie, aby się przekonać, że jednym z powodów usunięcia niektórych funkcji, była choćby ich nieprzydatność na ekranach dotykowych

Koordynatorem wszelkich zmian wprowadzanych w GNOME 3 jest William Jon McCann, który pracuje jako Senior Software Engineer w Red Hat i jako Core Developer & Designer w GNOME Foundation. Pozostaje pytanie tylko co z aplikacjami nazwijmy je "około GNOME". Z menadżerem plików, przeglądarką internetową, czy odtwarzaczem muzyki sprawa jest prosta, są to kluczowe programy i bezwzględnie są dostosowywane do wytycznych GNOME Shell. Weźmy dla przykładu taki Transmission, klient sieci BitTorrent posiadający interfejs dla Maca, GTK, Qt. Szczególnie popularny jest klient w wersji GTK, który jest domyślnym programem tego typu w wielu dystrybucjach z GNOME. Zapewne ten fakt skłonił wspominanego wcześniej McCanna do zasugerowania deweloperom Transmision usunięcia opcji "Show Transmission icon in the notification area". Powód był prozaiczny GNOME Shell nie wpiera tradycyjnego zasobnika systemowego, którego rolę przejął częściowo moduł powiadomień:

Odpowiedź dewelopera była, powiedzmy dosyć dosadna :

W skrócie chodzi o to aby dewelopery GNOME, Canonical usiedli razem i wypracowali wspólny standard i przestali "uprzykrzać" ;p, życie twórcom aplikacji.

Odpowiedź McCanna była rozbrajająca :

To są słowa głównego dizajnera i koordynatora prac nad GNOME 3, w skrócie Transmision powinien zdecydować co chce wpierać, GNOME, Unity czy XFCE. Tak było 2 lata temu. A jak sytuacja wygląda po drugiej stronie rzeki w Canonical/Ubuntu?. No cóż deweloperzy już myślą nad stworzeniem Ubuntu SDK. Wraz z premierą Ubuntu Phone jest to nawet konieczność.

Utopijni idealiści

Szczerze podziwiam ludzi z Elementary OS, bo to nad czym pracują w swoim wolnym czasie, robi ogromne wrażenie. Problem tylko w tym, że Red Hat i Canonical pracują nad tym samym, czyli nad w pełni zintegrowanym ekosystemem ze sporym zasobem aplikacji. A nawet przy ich zasobach średnio im to wychodzi. Nie należy zapominać także o programach napisanych z użyciem bibliotek Qt/KDE. W tym kontekście, żaden, nawet najlepszy HIG nie pomoże. Dorzućmy do tego aplikacje typu Libre Office, Firefox, Chrome, które mają w głębokim poważaniu to co robi grupka zapaleńców. Z tej perspektywy zespół Elementary OS wykonuje kawał dobrej, ale nikomu nie potrzebnej roboty.

Do sedna zatem

Na pytanie zawarte w tytule tego wpisu: "czy środowisk graficznych jest za dużo?", każdy powinien odpowiedzieć sobie sam. Zapewne wiele osób cieszy wszechobecna różnorodność, a dużą ilość "środowisk" oceniają jako normalny stan rzeczy. W części się zgodzę, tym bardziej, że ekosystem Linuksa nigdy nie był monolitem. Pamiętajmy, że nie mówimy tutaj o rzeszy bezimiennych programistów hakujących po nocach w swoim wolnym czasie, od których trudno cokolwiek wymagać. Jednak sytuacja w której dwaj najwięksi gracze nie mogą się dogadać, nie z przyczyn technicznych, a raczej z powodów własnego "widzimisię" jest nie do zaakceptowania. Jest to przykład wybitnego marnotrawstwa zasobów, które mogłyby zostać wykorzystane w bardziej pożyteczny sposób, ale niestety nie są.