O tym dlaczego spójny interfejs w Linuksie to fikcja
Co łączy deweloperów GNOME Shell i Elementary OS? Oba projekty marzą, aby zrobić z Linuksa, Mac OS. Oczywiście nie w sensie dosłownym, chodzi tu raczej o pewną filozofię interfejsu, która stawia wizualny aspekt systemu w centrum uwagi. Problem w tym, że takie działania są z góry skazane na niepowodzenie, a jedyne, na co możemy liczyć to opcja windowsowa, gdzie ponad jednolity wygląd aplikacji, ważniejsza jest "wolność" dla dewelopera, a okoliczny pejzaż to kompletny miszmasz aplikacji.
Bałagan zwany client-side decorations
Wraz GNOME 3.12 deweloperzy GNOME/GTK postanowili obdarować cały linuksowy świat wymysłami swoich megalomańskich projektantów. W tym celu twórcy GNOME postanowili użyć ciężkiego sprzętu w postaci client-side decorations. Pół biedy, gdyby nieczystości zostawili na swoim małym śmietnisku. Niestety wielki czerwony kapelusznik trzyma za klejnoty rodzinne nie tylko GNOME, ale i GTK i w ten sposób odór rozniósł się wszędzie. O tym, że client-side decorations to dół gnilny, pisał już w 2010 roku jeden z deweloperów KWin. Jako że, w chwili obecnej GTK to jeden wielki zamtuz, a Red Hat zachowuje się jak rajfur, można śmiało powiedzieć, że GNOME=GTK. Nic, więc dziwnego, że dosyć luźno powiązany z GNOME framework do tworzenia programów, stał się poligonem doświadczalnym projektantów.
GTK 3.12 - fuszerka fuszerkę pogania
Wraz z wersją GTK 3.12 deweloperzy wpadli na genialny pomysł, aby na stałe wprowadzić client-side decorations. Niestety implementacja to istna fuszerka, która prowadzi do różnych cudów na kiju. Otóż cała implementacja opiera się 20 letniej, mało używanej specyfikacji (mwm hints). Najlepsze jednak jest to, że ów "standard" nie dość, że słabo udokumentowany to zaimplementowany jest chyba tylko przed deweloperów GNOME. Oznacza, to ni mniej, że użytkownicy innych środowisk graficznych muszą się liczyć z różnymi dziwnymi rzeczami, jak choćby podwójne dekoracje okna.
Deweloperzy GNOME/GTK mają oczywiście tego świadomość, dlatego zgłosili nawet błąd na bugdzili XFCE.
GTK+ uses mwm hints to implement client-side decorations and custom titlebars. In particular, we are asking for a border, but no titlebar. Xfwm4 is so far the only window manager I've come across that supports mwm hints, but not this combination. Please consider supporting this. See the screenshot for the current, suboptimal user experience.
Błąd wywołał spore dyskusje, niemniej deweloperzy XFCE przygotowali odpowiednie zmiany, które czekają na wprowadzenie do głównej gałęzi XFCE.
Matthias Clasen, deweloper odpowiedzialny za wprowadzenie csd w GTK, radośnie oznajmił również, że wystarczy włączyć composite, a część problemów magicznie znika:
But anyway, if you use GTK+ 3.12.1, you will actually get full csd decorations under xfwm4, as long as compositing is enabled.
KWin vs CSD
XFCE to nie jedyne środowisko, któremu czkawką odbija się nowa wersja GTK oraz fuszerka jego deweloperów. Na liście mailingowej KDE również trwała dosyć burzliwa dyskusja co z tym fantem zrobić. Martin Gräßlin, jeden z głównych deweloperów zgłosił 14 różnych błędów, które występują, używając KWin jak menadżera okien. Niestety twórcy GNOME/GTK zdają się mieć w głębokim poważaniu inne środowiska graficzne, a sami wolą się taplać w swoim małym bagienku, zwanym GNOME. Przykładem takiego olewczego podejścia, jest choćby odpowiedź na błąd dotyczący jednej z kluczowych funkcji KWin, czyli możliwości wyłączenia efektów 3d/composite.
Tak jak w przypadku XFCE, jeśli mamy wyłączone efekty pulpitu to dostajemy podwójne dekoracje okna. Deweloperzy GNOME uważają jednak, możliwość wyłączenia efektów w locie za mało ważną.
I don't consider runtime changes of compositing to be a very high priority
W inny błędzie, ten sam deweloper sugeruje, aby KWin ograniczył swoje możliwości konfiguracji (chodzi tu o opcję pozwalającą na wyłączenie obramowania okna)
W sumie nie ma się co dziwić takiemu twardogłowemu podejściu, biorąc pod uwagę, techniczne zacofanie Muttera i jego spartańskie możliwości konfiguracji. Nie od dziś wiadomo przecież, że KWin jest technicznie najbardziej zaawansowanym menadżerem okien dla Linuksa, a tak prymitywna implementacja CSD, będzie jedynie działać prawidłowo w równie prymitywnym menadżerze okien, jak Mutter. Ktoś może zapytać, dlaczego KWin, nie zaimplementuje wymaganych przez GTK zmian. Normalnie deweloperzy zapewne by tak postąpili, problem w tym, że KWin, podobnie jak i cała powłoka Plasmy z serii 4.x jest od ponad roku zamrożona, a wymagane zmiany byłyby bardzo inwazyjne. Pozostaje również kwestia, dlaczego deweloperzy KDE mieliby się dostosowywać do zachcianek twórców GNOME?
elementaryOS - GNOME 3 w mikroskali
Naprawdę podziwiam pracę deweloperów i projektantów elementaryOS. Niczym Don Kichot naszych czasów, dzielnie walczą z interfejsowym marazmem w Linuksie, tworząc piękne i mało funkcjonalne aplikacje. Nic tam, że wystarczy zainstalować pierwszy lepszy program spoza środowiska i puff cały czar pryska. Deweloperzy zbudowali wokół swojej piaskownicy płot ze sztachet, jednak nie przeszkadza im to tworzyć zamki z piasku, w swoim małym wyimaginowanym świecie. Bohaterowie linuksowego pulpitu, utopijni marzyciele, którzy z rozmachem grzebią w swojej piaskownicy. Mają do tego prawo, a co. Dlatego ich nie krytykuję, bo poza grzebaniem w swoim małym błocku, tak naprawdę nic nie mogą zmienić, a co jeszcze bardziej istotne, można ich całkowicie zignorować. Pisze o tym, bo należy pamiętać, że deweloperzy i projektanci elementaryOS prezentują te same poglądy co twórcy GNOME Shell, brakuje im tylko zaplecza, aby swe wizje zrealizować. ElementaryOS może sobie być najpiękniejszą dystrybucją Linuksa, ale to, co naprawdę widzimy to pręty złotej klatki. Od każdego z nas zależy czy damy się zakuć w łańcuchy złudnej wizji spójnego interfejsu, tym bardziej że cena jest znacznie wyższa, niż wiele osób może przypuszczać.