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.

Budgie – ustawienia
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? 

0

21 komentarzy

  1. Dystrybucja Solus zapowiada się ciekawie i rewolucyjnie. Ciekawe ile czasu poświęcą na migrację środowiska Budgie do Qt i co z tego wyjdzie. Czekam z niecierpliwością.

  2. Budgie przestało się też lubić z moim Manjaro. Od przedostatniej aktualizacji zniknęły mi opcje wyłączania systemu i resetu. Teraz muszę to robić przez terminal 🙂

  3. Czyli tradycyjnie – rozwalamy coś co już działa i przepisujemy na nowo, bo i tak robimy to tylko tak dla zabawy, a nie żeby ktoś używał.

  4. Rozwalamy dlatego, by działać mogło i by nie być zaskakiwanym co kilka miesięcy nowymi pomysłami z bastionu Gnome.
    Ciekawi mnie natomiast dlaczego przez tyle miesięcy boksowali się z Gnome, a odchodzą od niego (przynajmniej zapowiadają), gdy Gnome 3.22 stało się LTS 🙂

  5. Pewnie dlatego, że chcą z Solusa zrobić permanentne rolling release? Wtedy każda nowa wersja GNOME zgodnie z koncepcją systemu – powinno się w nim pojawić, bez oglądania się na LTS.

    Ale przy takich założeniach to wątpię aby uniknęli podobnych problemów z Qt.

  6. Unity 8 ma być w QT, niedawno LXDE przeszło na QT jako LX-QT. Zostało jedynie to Gnome i Xfce które chyba przepiszą do GTK3 tak jak Gnome. A Cinnamon też taki zlepek C, Pythona, JavaScript i GTK3. Co do języka Vala to on jest dopiero kompilowany do C, więc raczej ciut wolniejszy. W sumie mogli by i w Rust pisać. Bezpieczny szybki język programowania od Mozilli. Nie wiem też czy to środowisko graficzne Lumina od TrueOS(PC-BSD) nie jest też w QT. Co do Gnome GTK to przecież ono powstało ze względu na licencje QT, chcieli bardziej otwartej biblioteki. No i ekipa Redhat, Linux, Fedora tworzy kernel Linux więc bardziej związani są z językiem C niż C++, takie jest moje zdanie. Musieli by jedynie przepisać GTK na nowo w bardziej nowoczesnym stylu przy użyciu C++, tego swojego Vala lub Rust, ponieważ C i GTK jest już na te czasy trochę przestarzałe, wolno się w tym pisze i trudno wyszukuje błędy, bugi. Plasma dość szybko wykorzystuje standardy teraz C++17 i QT5.

  7. „Ale przy takich założeniach to wątpię aby uniknęli podobnych problemów z Qt.”
    Z tego co widzę – w dużej mierze te problemy się udaje ominąć, choć w istocie np. Qt5.8 rozwaliło (do cna) możliwość uruchamiania Plasmy na Waylandzie. Budgie jest jednak – jak dotąd – rozwiązaniem Xowym, zatem coś takiego im raczej nie grozi. Nawet nadchodzące Qt6 nie powinno czynić (przynajmniej w zamierzeniach) jakichś większych zmian, bo ma być 100% kompatybilne.

  8. LXDE nie przeszło na Qt. LXDE nadal jest na Gtk, a obok niego istnieje projekt LXQT. Na Gtk wbrew pozorom jest chyba więcej DE niż na Qt. Oprócz wymienionych przez Ciebie Gnome i XFCE jest właśnie LXDE, MATE, Cinnamon, Deepin (a to w sumie hybryda Gtk i Qt), do tej pory Budgie i Unity. Jest też sporo mniej znanych środowisk, szczególnie tych, które są na Waylanda.
    Lumina jest na Qt5 (wyłącznie, nie korzysta nawet z KF5). W sumie spośród tych, które przebiły się do świadomości, to na Qt jest tylko KDE, LXQT, wspomniana Lumina i kilka dla Waylanda, które wraz z Qt5.8 zaprzestają się uruchamiać 🙂 Przynajmniej na razie. Unity 8 ponoć ma się pojawić w kwietniu. Zobaczymy (niedawno ściągnięte przeze mnie daily Ubuntu nadal miało Unity 7).
    Zobaczymy również co przyniesie Gtk4, które powinno się chyba nawet już ukazać.

  9. Dzięki,mam już 18.1 od bety (od dawna):).
    Cytowałem wypowiedź jakiegoś dewelopera xfce.

  10. Na razie ukazały się dwa snapshoty gtk+3.89, które kiedyś stanie się gtk4. To nas czeka najprawdopodobniej w 2019. Jest więc trochę czasu na uwolnienie się od wielkiego znaku zapytania 😉 Z tego co pamiętam to deweloperzy gnome wciąż myślą o własnym systemie. Gnome3 (z jego wszystkimi niedoskonałościami) było więc tylko przedsmakiem.

  11. Ale przecież nie musieli korzystać z całego gnome, a z samego gtk, w którym to, w moim odczuciu, się programuje łatwiej niż w Qt.

  12. Długo nie sprawdzałem Mint Xfce. Jeśli sięgałem po Minta to raczej z Cinnamonem. Wczoraj pobrałem i uruchomiłem w live. Chciałem sprawdzić jak zachowuje się z compiz i przyznam, że się zdziwiłem, gdy przy próbie instalacji terminal mi wywalił, że wszystkie pakiety są zainstalowane i aktualne. Wystarczyło dać compiz –replace i po sprawie. Do tego wszystko działało bardzo sprawnie (przynajmniej przez te 15 minut jak to sobie testowałem).
    Od dawna dodają compiz out of the box w Mint Xfce? No i jak to się sprawuje w praktyce? (nie chcę na razie zmieniać Manjaro, jestem z niego bardzo zadowolony, dlatego pytam z ciekawości, zamiast samemu się przekonywać;)

  13. Compiza można włączyć w ustawieniach pulpitu,nie trzeba przez –replace.
    Dają chyba od 17.Działa to bardzo sprawnie,ja używam w sumie xfwm,bo Compiz nie potrzebuję.
    W Manjaro xfce też działa to bardzo sprawnie,mówie o Compiz,nawet trochę lepiej,bo można bez problemu zmienić dekorację okna z działającym Compizem,a w Mint trzeba sie troche zmęczyć

  14. Osobiście tak się przyzwyczaiłem do hot corners, kiedyś na osx, potem na Ubuntu, że nie umiem już się odnaleźć bez tego. Dlatego compiz to jedna z pierwszych rzeczy, które instaluje pod Xfce.
    Manjaro chyba pierwsze wyskoczyło z Compiz, może dlatego jest tam ciut lepiej. Najpierw za dekorację okien odpowiadał Emerald, a teraz jest Compiz GTK Decorator. (choć Emeralda też można doinstalować, problem w tym, że już chyba nikt nie robi pod niego tematów, a szkoda, wolałem jego niż ten nowy twór, który jak wszystko dziś jest bardziej flat – czego nie lubię, w Androidzie czy Windows nie mam wyboru, zatem choć w Linuxie wolałbym coś innego niż ten wszechobecny ostatnio flat – no ale co zrobić, taka moda;)
    Pod Mintem też pewnie można by użyć Emeralda? Czy się tam z czymś gryzie? widziałem na sieci, że używa się dconf, emerald chyba byłby wygodniejszy? tyle że jak pisałem brak do niego nowych themes.

  15. Kurczak dzięki za cynk 🙂 Po aktualizacji wywaliło mi aplet z panelu. Po prostu wystarczyło go dodać 🙂 Na swoją obronę muszę dodać, że nie spodziewałem się, że User Indicator to będzie to (ikona w menu aplety przedstawia „użytkownika”, a po dodaniu do panelu zmienia się na znak „włączenia/wyłączenia” – taki dowcip programistów). Pzdr

  16. Większym problemem jest to, że „mandżur” złapał małą czkawkę po ostatniej aktualizacji.
    Konkretnie LightDM w spinach Gnome i pokrewnych. Szczęśliwie jest już tymczasowe rozwiązanie.
    Na GDM problem nie występuje.

  17. Hotcorners w xfwm zrobisz:
    xfce4-hotcorner-plugin + np. skippy-xd

    Klawisz z flagą przymapujesz do menu za pomocą np:
    xcape -e „Super_L=Alt_L|F1”

    xfwm jest spoko.

  18. Tak i nie rozumiem tej niechęci do GtkHeaderBar, imho z tym aplikacje wyglądają lepiej, mają taką samą funkcjonalność i 3x niższe paski u góry aplikacji (na panoramiczne monitory w sam raz). Niech sobie tak będzie!

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Post comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.