Czy dystrybucje powinny "poprawiać" środowisko graficzne?

To pytanie powraca do mnie niczym bumerang, dlatego postanowiłem coś z tym zrobić. W paru zdaniach postaram się więc opisać kilka osobistych przemyśleń, przedstawiając je w skondensowanej formie wpisu blogowego. Niektórzy mogą się zastanawiać, co mam na myśli poprzez "poprawianie" środowiska graficznego. Jako przykład wezmę KDE, co nie powinno dziwić zważywszy na tematykę tego bloga. Nie mniej niektóre spostrzeżenia, można by zapewne odnieść do pozostałych "desktop enviroments"

Elementy składowe

KDE jest o tyle ciekawym projektem, bo zapewnia nie tylko powłokę (KDE Plasma Workspaces), dzięki której możemy "komunikować się", czyli zmieniać i modyfikować ustawienia systemu ( najczęściej Linux), ale dostarcza również programów powiązanych z samym środowiskiem (KDE Applications). Zarówno powłoka jak i aplikacje korzystają z tych samych bibliotek, które stanowią fundament i materiał budulcowy, w oficjalnym nazewnictwie noszą one miano (KDE Platform). I tak powoli dochodzimy do sedna problemu. Okazuje się bowiem, że nie ma jasno określonych granic tego czy dana aplikacja lub projekt jest częścią KDE. Ile osób wie, że  ownCloud czy Necessitas (port Qt na androida) są projektami KDE. Chociaż w tym przypadku, należałoby użyć stwierdzenia "pod patronatem" KDE. Innymi słowy, każdy projekt czy program, którego deweloperzy wyrażą taką chęć, może stać się "częścią" KDE. To powinno niektórym uświadomić jak cienkie są owe powiązania. Dodajmy do tego fakt, że sami twórcy niejako zachęcają (poprzez danie szerokich możliwości konfiguracji) do zmiany wielu elementów środowiska. Inną kwestią jest dojrzałość niektórych z elementów składowych. W przypadku KDE, największe kontrowersje budzą nepomuk i pakiet programów znany pod nazwą KDE PIM . W tym ostatnim przypadku szczególnie złą sławą okrył się kmail. Warto sobie jednak uświadomić, że to DEWELOPERZY danej aplikacji decydują o tym czy jest ona gotowa. Także tak długo jak dany projekt jest AKTYWNIE rozwijany (nawet jeśli jego stan można określić jako niestabilny/nieużywalny) tak długo projekt ten ma PRWAO być częścią KDE. Podsumujmy zatem kilka faktów.

• To co znamy pod nazwę KDE opisuje kilka głównych elementów składowych (KDE Plasma Workspaces, KDE Applications, KDE Platform)
• Każdy projekt może stać się częścią KDE jeśli spełni kilka bliżej nieokreślonych wymogów.
• Wiele z tych projektów/aplikacji jest bardzo luźno powiązana z samym KDE (ownCloud, Necessitas)
• Raz przyjęty projekt ma PRAWO być częścią KDE, tak długo jak jest AKTYWNIE rozwijany, niezależnie od stanu jego "UŻYWALNOŚCI"
• O tym czy dany projekt/program jest "UŻYWALNY" decyduje tylko i wyłącznie DEWELOPER tego projektu/aplikacji.

Wszytko to sprawia, że:

• KDE jako środowisko graficzne składające się z WIELU (często luźno) powiązanych ze sobą projektów NIE MA REALNEGO WPŁYWU (niezależnie od ich faktycznego stanu używalności) na poszczególne jego elementy składowe, tak długo jak dany projekt jest AKTYWNIE rozwijany.

Niektórzy uznają to za paradoks, jednak taka jest natura projektu open source, w którym wszyscy deweloperzy mają równe prawa, gdzie nie ma dokładnie ustalonych barier wejścia. Dorzućmy do tego, że wszyscy członkowie społeczności deweloperskiej mają wspólny cel, ale jest on bardzo OGÓLNIE sformułowany. KDE jest więc mieszaniną, rożnych firm i organizacji oraz niezrzeszonych deweloperów "hakujących" po nocach. Przy czym żadna z tych grup nie ma decydującego wpływu na całość projektu. To co ich łączy to wspólna pasja i poczucie wizji. Niektórzy uznaliby to za szczyt anarchii, jednak w praktyce taki system spisuje się całkiem nieźle. Z jednej strony łączy w sobie łatwość partycypacji, bo każdy posiadający stosowne umiejętności może w nim uczestniczyć, a decyzje podejmowane są drogą konsensusu. Wadą takiego rozwiązania jest fakt, że jedno niesprawne ogniwo, może rzutować na opinię o całym projekcie (wspomniany wcześniej nepomuk, kmail). No dobra, kto zatem zbiera te luźno powiązane elementy zwane KDE do kupy i decyduje o tym, który z nich jest gotowy dla końcowego odbiorcy (użytkownika). Odpowiedź jest prosta, tym scalającym wszystkie części ogniwem, są deweloperzy dystrybucji.

Dystrybucja dystrybucji nie równa

Biorąc pod uwagę wszystkie wypomniane powyżej zawiłości procesu tworzenia KDE, cała ODPOWIEDZIALNOŚĆ na końcowy kształt/rezultat, czyli to czego używają użytkownicy, spada na DEWELOPERÓW DANEJ DYSTRYBUCJI. Niestety większość z nich wyznaje zasadę to "co fabryka dała". Poniżej przedstawię "listę błędów" jakie popełnia wiele dystrybucji. Zawierają one również, wiele z moich osobistych wizji/przekonań jak powinna wyglądać dystrybucja z KDE

Wyróżniaj się lub giń

Czy tak trudno zmienić tapetę albo domyślny styl? Jasne, że nie, to dlaczego tak mało dystrybucji to robi. Nie mówię tu od razu o nowym motywie ikon, wystarczy subtelna zmiana ekranu logowania (KDM), własny motyw plasmy czy choćby głupia zmiana tapety. Niestety zbyt często słyszę, że wszystkie dystrybucje KDE wyglądają tak samo. A jak mają wyglądać, jak niektóre prawie nic nie zmieniają?

Domyślne programy i głupie ograniczenia

Tego nijak nie mogę zrozumieć. Jak można być takim idiotą, żeby dawać rekonq jako domyślną przeglądarkę? Czy tak trudno wrzucić firefoxa? Albo zarządzanie oprogramowaniem. Jeszcze do niedawna pewna dystrybucja z K w nazwie była nieużywalna bo zamiast synaptica, dawali marną namiastkę zwaną kpackagekit. Mam tu na myśli niechęć do używania aplikacji non KDE/Qt. Co jest złego we wrzuceniu programu napisanego w "czystym" GTK (synaptic, pidgin) albo neutralnego (Firefox, Thunderbird). Dla nie wiedzących Firefox i Thunderbird są napisane w XUL, a GTK używają jedynie, a dla niektórych aż, do skórkowania. Sztampowy przykład kmail 2, skoro dystrybucje decydują się na jego włączenie, to niech zadbają aby działał. A jeśli nie, to niech dadzą aplikację która działa (Thunderbird). Dla mnie sprawa jest jasna, jeśli jakaś aplikacja jest domyślnie i nie działa, to jest to w głównej mierze wina deweloperów danej dystrybucji. Zależności z  GNOME to nie problem, bo większość programów napisanych w czystym GTK takich nie posiada. Miejsce to również nie problem, bo większość dystrybucji i tak udostępnia wersję dvd (openSUSE, Mageia, Mint). Integrację wizualną zapewnia oxygen-gtk. Jedynym ograniczeniem są tępi deweloperzy.

Domyślne ustawienia

Skoro jakaś dystrybucja decyduje się na włączenie nepomuka, akonadi czy innych usług, to niech się upewnią, że one działają. Jeśli nie to niech je wyłączą domyślnie i czekają, aż nieliczni deweloperzy, którzy nad nimi pracują, je naprawią. A jeśli nie chce im się czekać (czasem nawet kilku lat), to niech z łaski swojej zatrudnią programistów, którzy pomogą tym nielicznym deweloperom. Proste, niestety wielu twardogłowych deweloperów dystrybucji ma to gdzieś, że tak się wyrażę. Tak, więc następnym razem szanowny użytkowniku, zamiast obwiniać twórców KDE, za fuszerki, warto się zastanowić nad tym kto jest za nie NAPRAWDĘ odpowiedzialny.