Co nowego w KDE 4?

Poniższy tekst jest tłumaczeniem materiału opublikowanego na blogu /home/liquidat. Przedstawia on najważniejsze zmiany które zaszły pomiędzy KDE 3 a KDE 4. Polskie tłumaczenie pierwotnie ukazało się na stronie kde.org.pl
Pierwsze wydanie KDE 4 będzie zawierało kilka dużych zmian w stosunku do wersji poprzedniej – KDE 3.x. Objaśnienia tych zmian były już wprawdzie publikowane w kilku miejscach. Niniejsza notka ta powstała jednak aby lepiej wyjaśnić użytkownikom przyczyny zachodzących zmian.

KDE 4 będzie wielkim krokiem w stosunku do KDE 3. Na blogu już wcześniej opublikowałem listę programów, które zostaną zastąpione innymi. Lista ta nie mówiła jednak o przyczynach tych zmian. Wraz ze zbliżaniem się wydania KDE 4.0, dostępne jest więcej nowych i prostszych możliwości przetestowania świeżych wersji KDE. Ludzie coraz częściej pytają, dlaczego niektóre techniki stosowane w KDE 3 nie znajdą swego miejsca w KDE 4 lub dlaczego niektóre usługi zostały zastąpione nowymi. Nawet mój przyjaciel – normalny użytkownik, nie interesujący się rozwojem KDE 4 – był zaniepokojony brakiem pewnych funkcji. Kolejnym powodem, dla którego powstała ta notka jest fakt, że nawet w serwisie Planet KDE trwają dyskusje na ten temat zachodzących zmian. Rzuciłem więc trochę światła na powody zachodzących zmian projektowych z punktu widzenia użytkownika.
aRts kontra Phonon
Powód zmiany jest bardzo prosty: aRts – serwer dźwięku w KDE 3 – był dość zaawansowany, jednak nie był już rozwijany. Mimo zastosowania najnowszych technik w momencie jego premiery, do czasu kiedy zaczęto prace nad KDE 4 był już mocno przestarzały – brakowało na przykład obsługi dla filmów. aRts wymagałby znacznych zmian oraz dodania wielu nowych funkcji. Nie było jednak chętnego do wykonania tej pracy. W tym samym czasie istniały już doskonałe silniki do obsługi multimediów (Xine, Mplayer) lub rozwijały się nowe (Gstreamer).
Utrzymywanie uzależnienia KDE 3 do aRts tylko zaszkodziło multimediom tego środowiska graficznego w końcowym okresie jego rozwoju. Programiści KDE nie chcieli aby to się powtórzyło. Zdecydowano, że najlepszym rozwiązaniem będzie stworzenie oprogramowania, które mogłoby wykorzystywać istniejące silniki obsługi multimediów. Ktoś wziął się do roboty i tak właśnie powstał Phonon.
Powstaje oczywiście pytanie czy jest to właściwa droga. Czas pokaże, ale Trolltech już zdecydował o włączeniu Phonona do Qt 4.4.
KControl kontra SystemSettings
KControl (Centrum sterowania KDE) zostanie zastąpione przez SystemSettings, ale są osoby, którym SystemSettings się nie podoba. Uważam, że powinny one jeszcze raz przyjrzeć się tej aplikacji, gdyż SystemSettings po prostu ładuje moduły KControl. Nowy jest zatem tylko interfejs dostępu do modułów, a same moduły są takie same (oczywiście ze zmianami, które daje nam KDE 4). Powodem wprowadzenia rozwiązania SystemSettings są duże związane z nim możliwości oraz życzenia użytkowników: SystemSettings po raz pierwszy pojawił się w KDE zmodyfikowanym dla potrzeb Kubuntu i spodobał się użytkownikom – był bardziej dopracowany, użyteczny i łatwiejszy w obsłudze. Kolejną przyczyną zmiany było to, że KControl nie miał już opiekuna.
Oczywiście długoletni użytkownicy KDE mają mieszane uczucia. Ludzie tacy jak ja, często już przywykli do wyglądu i zachowania KControl. Głównym celem jest ułatwienie pracy zwykłym użytkownikom. Z tego co wyczytałem o SystemSettings, zastąpienie KControl programistom czy zaawansowanym użytkownikom nie zrobi zbytniej różnicy ponieważ funkcjonalność jest podobna, a moduły pozostają te same. Jeśli zaś zmiana nie jest dla nich szczególnie istotna, a tylko jedno SystemSettings jest aktualnie rozwijane, wybór okazał się prosty.
Oxygen
Oxygen jest najbardziej widoczną częścią KDE, ponieważ definiuje zestaw ikon oraz motyw. Wcześniej wspomniany kolega twierdził, że nowy motyw mu się nie podoba. Ja z kolei lubię jasne, mleczne motywy z małym kontrastem. Jesteśmy zaawansowanymi użytkownikami i wiemy, że motyw można zmienić w kilka sekund, a silnik obsługi motywów ma bardzo duże możliwości. Dla przeciętnego użytkownika KDE musi być ładne, a ładne są mleczne motywy z niewielkim kontrastem. Kolejną przyczyną zastosowania motywu z Oxygen są własne odczucia twórców Oxygena i jak sądzę, chęć przetestowania możliwości KDE 4. Z tego właśnie powodu została podjęta decyzja o wyborze wyglądu KDE 4. Każdy zaawansowany użytkownik nie powinien się przejmować ikonami czy motywem. W końcu wie o istnieniu czegoś takiego jak kde-look.org
Ważne jest jednocześnie, aby KDE 4.0 było dostępne z zestawem różnych ikon i motywów, by każdy użytkownik mógł wybrać coś dla siebie. Innym rozwiązaniem jest po prostu odpowiednie zastosowanie mechanizmu GetHotNewStuff.
Kicker kontra Plasma
Panel w KDE 4 jest gorącym, często omawianym w ciągu ostatnich dni w gronie programistów KDE tematem. Problemem jest to, że panel Plasmy obecnie nie działa dokładnie tak jak Kicker (panel KDE 3). Dlaczego więc porzucono kickera i stworzono coś nowego zamiast po prostu dodać nowe funkcje do kickera?
Problemem jest to, że budowa Kickera już od dłuższego czasu jest „popsuta”: kod źródłowy jest bardzo nieczytelny, nowo dodawane opcje wprowadzały też wiele błędów. Kicker nie był też zupełnie przenośny między platformami systemowymi. Projekty które chciały dodać do Kickera jakąś ciekawą funkcję zazwyczaj kończyły tak, że kopiowały kod źródłowy Kickera i modyfikowały go, czyli po prostu tworzyły tzw. forka. Nie byłoby to konieczne, gdyby kicker był lepiej zaprojektowany. Został on jednak stworzony dla KDE 2.0 (!). W tamtym czasie nikt nie przypuszczał, że aplety będzie można osadzać zarówno na panelu jak i na pulpicie, albo że pojawi się kilka nowych pomysłów dotyczących paneli i Kicker nie będzie on już taki statyczny jak wcześniej (pomyśl np. rozwiązaniu rodem z panelu systemu MacOS).
Ważną rzeczą jest to, aby kod źródłowy był łatwy w utrzymaniu – KDE 4 będzie miało dość długie życie. Pojawiły się więc dwie możliwości: albo zupełnie przerobić Kickera, tak aby mógł współdzielić część kodu źródłowego z Superkarambą, albo stworzyć jakiś zamiennik. Zdecydowano się na połączenie panelu z pulpitem. Była to odważna decyzja: projekt Plasma, mimo że każdego dnia robi postępy, jest szeroko krytykowana. Nadal brakuje jej także pewnych funkcji.
Z punktu widzenia użytkownika będzie na pewno kilka rzeczy, do których trzeba będzie się przyzwyczaić, przy czym będzie brakowało też kilku funkcji znanych z Kickera. Oczywiście dostępne będą wszystkie podstawowe funkcje panelu, jednak będzie to zupełnie nowa aplikacja. Należy się do tego przyzwyczaić, a to na pewno będzie wymagało czasu. Jedną z zalet nowego panelu jest to, że jest on o wiele bardziej elastyczny, więc po pewnym czasie na pewno pojawi się wiele ulepszeń. Nawet jeśli znajdą się jakieś nowe pomysły na panel, nie będą one wymagały zastąpienia aktualnego panelu. Konstrukcja istniejącego panel będzie mogła zostać wykorzystana.
Jeśli martwicie się o aktualny wygląd: nie jest on jeszcze ostateczny. Dla Plasmy można bezproblemowo zmieniać motywy i nie jest jeszcze określone jak będzie wyglądać wersja ostateczna. Być może będzie zupełnie inna, aby podkreślić różnicę między wersją stabilną a wersjami Beta i RC.
KMenu kontra Kickoff
Kolejne źródło emocji: klasyczne menu z KDE 3 zostanie zastąpione przez Kickoff, który został stworzony przez openSUSE/Novell i był używany w nowszych edycjach openSUSE. Osoby przywykłe do klasycznego menu z MS Windows czy KDE 3 będą na pewno zdezorientowani, kiedy po raz pierwszy zobaczą Kickoff. Denerwujące może być trochę odmienne zachowanie.
Dlaczego zdecydowano się na zmianę? Jedną z przyczyn ponownie była słaba jakość kodu źródłowego cechująca poprzednie rozwiązanie. Novell poświęcił wiele czasu i pieniędzy na przeprowadzenie badań dotyczących wyglądu i zachowania menu, aby było jak najbardziej użyteczne. Po rozmowach z użytkownikami okazało się, że lubią oni klasyczne menu tylko dlatego, że do niego przywykli – jego użyteczność nie miała znaczenia. Pod względem użyteczności szaleństwem jest nawigowanie po takim menu za pomocą myszki. (Czy muszę dodawać, że nie korzystam z menu, jeśli tylko mogę tego uniknąć? Niech żyje Alt+F2!) Prace nad Kickoff rozpoczęto mając w pamięci opinie użytkowników.
Użyteczność Kickoffa jest o wiele większa od użyteczności starego menu. To nic, że osobiście się z tym nie zgadzasz – zostało to dowiedzione podczas badań. Kickoff został już przeniesiony do KDE 4. Początkowo planowano jeszcze inne menu, ale prace się opóźniły.
Nowi użytkownicy KDE są w dość dobre sytuacji. Ci przyzwyczajeni do starego KMenu już nie, ale mając Plasmę dostają możliwość zastąpienia Kickoffa innym menu. Aktualnie powstaje już inne menu: Lancelot. Nie powinno być także problemów ze zbudowaniem odpowiednika starego menu dla ludzi, którzy wolą żyć w epoce kamienia łupanego lat 90.
Konqueror oraz Dolphin („oraz” a nie „kontra”)
Dolphin jest nowym menadżerem plików dla KDE 4. Wiele osób jest tym zaniepokojonych. Szczególnie obawiają się tego użytkownicy zaawansowani, dla których usunięcie Konquerora mogłoby być horrorem. Konqueror jest swoistym szwajcarskim scyzorykiem do wszystkiego co jest choć trochę związane z zarządzeniem plikami. Jest narzędziem dla zaawansowanych użytkowników.
Dlaczego w ogóle pojawił się Dolphin? Pierwszym powodem jest to, że Dolpin stał się dość popularny w momencie, kiedy rozpoczynano prace nad KDE 4. Kolejny powód to fakt, że wielu użytkowników chce prostego menadżera plików a nie szwajcarskiego scyzoryka. Była to też szansa na ulepszenie Konquerora: programiści Dolphina zostali zaproszeni do wspólnej pracy, dzięki czemu Konqueror do zarządzania plikami wykorzystuje teraz silnik Dolphina.
Oczywiście z powodu nagłego zainteresowania Dolphinem Konqueror nie został zapomniany. Najnowsze informacje pokazują, że Konqueror został nawet wzbogacony o nowe funkcje.
Podsumowanie
Powyższa lista omawia tylko najważniejsze zmiany, gdyż wszystkich zmian jest oczywiście o wiele więcej. Chciałbym dodać, że większość informacji pochodzi z blogów, newsów i komentarzy na stronach KDE. Niektóre argumenty zależą od punktu widzenia programistów, więc nie wszyscy muszą się z nimi zgadzać.
Ten tekst jest tłumaczeniem artykułu KDE 4: some reasons for design decisions autorstwa liquidata. Tekst jest dostępny na licencji Creative Commons Attribution – ShareAlike 3.0..
Archiwalny news dodany przez użytkownika: liquidat.
Kliknij tutaj by zobaczyć archiwalne komentarze.