Budgie już nie lubi GNOME

A raczej nie lubi go Ikey Doherty, osoba odpowiedzialna za dystrybucję Solus i środowisko Budgie. Może „nie lubi” jest tutaj mocno na wyrost, ale GNOME dało się Ikeyowi już mocno we znaki. Chodzi oczywiście o dynamiczne API i ABI, które stały się synonimem technologicznej rewolucji pod przewodnictwem deweloperów tego środowiska. Choć Budgie nie ma ambicji bycia forkiem GNOME ani kolejnym GNOME-Shell, to zmiany przy GNOME 3.18, 3.20 i tak dalej powodują, że deweloperzy Solusa mają pełne ręce roboty. W związku z tym, decyzja mogła być tylko jedna – w imię rozwoju środowiska muszą zostać podjęte odpowiednie kroki. Zmierzające w stronę Qt.

Ikey w rzeczowym poście zapowiadającym prace nad Budgie 11 poświęcił temu rozbratowi z GNOME większość swojego wpisu. W sumie, cały wpis stanowi wytłumaczenie, dlaczego GNOME staje się kłodą na ścieżce dynamicznego i ambitnego rozwoju środowiska Budgie. Zasadniczo Budgie miało się zgrabnie integrować z programami GNOME. Okazało się jednak, że te aplikacje same dążą do takiej integracji z GNOME, że utrzymanie tego samego stanu w Budgie stało się uciążliwe. Nawet bardzo. A z czasem nawet i bezsensowne. Każde główne wydanie GNOME powodowało sporo problemów – zaczęło się od 3.10 i stan ten trwał do 3.22. Łączenie składników systemu w jedno, rozdzielanie, (Mutter, cogl, clutter), drobne zmiany w API, niekompatybilności w ABI, rozsypujące się widżety i tematy graficzne, API GdkScreen zmieniające swoje oblicze i długo by tak wymieniać. Wydaje się, że GNOME realizuje swoją własną wizję rozwoju swojego własnego środowiska bez oglądania się na uniwersalność i przewidywalność tworzonych rozwiązań. Może ma to jakiś ukryty sens, ale zupełnie nieprzydatny w momencie chęci „odchudzonego” pulpitu pozostającego jednak w zgodzie z technologią rozwijaną w GNOME.

Narastająca liczba elementów w GNOME komunikujących się między sobą powoduje, że taki sam łańcuch zależności musi powstać i w Budgie. Co więcej, elementy te ewoluują, pączkują, uzależniają się jedne od drugich. W efekcie prace nad Budgie zaczęły przypominać forkowanie GNOME i próbę odtworzenia zachodzących tam procesów. Jest to niezbędne do funkcjonowania środowiska. Wystarczy dodać, że aby wyświetlać pospolite powiadomienia i dogadać się z widżetami konieczne jest duplikowanie zachowania tych elementów w GNOME.

Aby zerwać z GNOME pod uwagę brano EFL (stworzone na potrzeby środowiska Enlightenment), lecz pomysł ten porzucono z racji problemów zbliżonych do tych z Glib. Do wyboru pozostało zatem znane i lubiane Qt (ok, można rozpatrywać jeszcze FLTK, ale wizualnie odbiega ono od koncepcji Budgie). Jednocześnie postanowiono rozwijać środowisko z wykorzystaniem języka C++ – w miejsce Vala. Dodatkowo Ikey chce uniknąć QML (i Javascriptu na pulpicie), ominąć kompletnie biblioteki KDE (i framework) i stworzyć środowisko uniwersalne, nowoczesne i na miarę naszych czasów. Co z tego wyjdzie – zobaczymy, jednak dlaczego od samego początku nikt nie zwrócił uwagi na specyfikę rozwoju GNOME?