W tym tygodniu tłumaczenie kolejnego wywiadu. Wywiad przeprowadzono z Benjaminem Reedem, Jarosławem Stańkiem i Ralfem Habackerem, programistami zajmującymi się portowaniem środowiska KDE na platformy Macintosh i Windows.

Wywiad przeprowadził Scott Ruecker w styczniu 2007. Oryginalny tekst znajduje się na stronach serwisu LXer.

Umożliwiając uruchamianie aplikacji KDE w systemach Macintosh i MS Windows, liczba potencjalnych użytkowników wolnego oprogramowania staje się wręcz nieograniczona. Wyobraźmy sobie miliony ludzi używających oprogramowania Open Source po raz pierwszy i… zachwycających się nim.

Niedawno miałem możliwość porozmawiania z kilkoma programistami KDE. Benjamin Reed, Jarosław Staniek i Ralf Habacker są młodymi, utalentowanymi programistami pracującymi nad przeniesieniem KDE na platformy Mac i Windows. Wyjaśnią oni z detalami na czym polega czynienie KDE wraz z mnóstwem jego aplikacji zdolnym do działania w systemach Mac i Windows.

Czy moglibyście powiedzieć coś o technicznych aspektach przenoszenia programów na platformy Mac i Windows?

Jarosław

Będę się odnosił do KDE/Windows jako do „bibliotek KDE dla Windows wraz z pewną liczbą aplikacji KDE”. Przenosząc KDE na tę platformę znaczna większość kodu programów pozostaje bez zmian. Tu jako przykład mogę podać kod źródłowy aplikacji Kexi, którą rozwijam na platformie Windows. Zmiany w kodzie są często przekazywane do do repozytorium kodu źródłowego KDE (Subversion) bez dodatkowego sprawdzania jego działania na innych platformach. Potem uaktualniam inną kopię tego samego kodu źródłowego z Subversion i rekompiluję go na Linuksie. Pojawiają się wtedy co najwyżej drobne błędy kompilacji, wynikające z zastosowania różnych kompilatorów. W przybliżeniu w taki sposób odbywa się przenoszenie czyli „portowanie”.
Podczas przystosowywania aplikacji staramy się użyć natywnych właściwości interfejsu danego systemu operacyjnego tak dalece jak tylko jest to możliwe. Myślę, że wielu programistów zgodzi się ze mną, iż jest to dobre rozwiązanie. W żadnym natomiast wypadku nie wykonujemy „forków” (czyli oderwania projektu od oryginalnej wersji), które czyniłyby aplikacje niestandardowymi w sensie formatu plików czy protokołów. Osobiście czasem wolę zrezygnować z pewnych funkcji programu (lub obejść problem) niż zostać zmuszonym do skorzystania z własnościowych rozwiązań dostępnych w danym systemie operacyjnym. Przykładem niech tutaj będzie używanie przeze mnie biblioteki mdbtools w celu uzyskania dostępu do formatu plików baz danych programu MS Access zamiast wykorzystania natywnego interfejsu programistycznego Windows DAO czy ADO. Nie jest to wyłącznie sprawa licencji (wiele tego typu bibliotek jest uważanych jako część systemu operacyjnego), ale przyjętej przeze mnie strategii.
Innym przykładem wykorzystania warstwy niższego poziomu bezpośrednio z systemu operacyjnego jest framework do obsługi multimediów. Z kolei przykładem elementu systemu, który nie powinien zostać zastąpione podczas używania KDE na Windows przez typowego użytkownika jest systemowy pulpit explorer.exe.

Benjamin

Dla przenoszenia KDE na Mac OS X w chwili obecnej nie ma żadnego specjalnego projektu technicznego ponad ten, które generalnie oferuje KDE. Wszystko co jest niezbędne już jest zawarte w kodzie i projekcie tego środowiska. Zdaję sobie sprawę, że nie jest to wyczerpująca wypowiedź więc odwołam się tutaj do historii tego projektu.
Największą pracę wykonał Sam Magnuson (pracownik firmy Trolltech) rozdzielając tę część kodu KDE3, która była powiązana z X Window System i kompilując ją z użyciem bibliotek Qt/Mac 3.x. Wykorzystałem efekty jego prac poprawiając jakość i wygląd kodu. Mniej więcej w tym samym czasie zespół portujący KDE na Windows wykonywał podobne zadanie. Czas mijał, a prace posuwały się bardzo powoli, głownie z tego powodu, że jestem raczej kiepskim programistą C++ i osiągnąłem już szczyt swoich możliwości. Wykonywałem więc dalej tą pracę samodzielnie i chociaż było wiele zainteresowanych osób, nikt nie miał czasu by mi pomóc. Najwięcej czasu zajmowała mi zarządzanie pakietami Fink, ich aktualizowanie i dopracowywanie. W tym samym czasie zespół Windows wykonał dużo niesamowitej pracy, którą połączył z wynikami osiągniętymi przez Sama Magnusona i przeze mnie.
W trakcie prac nad KDE 4 rozmawiałem na kanale IRC #kde-devel z kilkoma programistami o problemach portowania na Mac oraz o konieczności zajęcia się tym problemem. Jednym z elementów znacznie to ułatwiających było przeniesienie KDE na Qt 4 oraz użycie (niezależnych od systemu operacyjnego interfejsów) programistycznych Qt dla tych składników KDE, które były wcześniej zależne od X Window System. Firma Trolltech zobowiązała się też do udostępnienia w Qt odpowiednich interfejsów programistycznych dla elementów KDE, które wcześniej potrzebowały „nieczystych” rozwiązań. Poza tym zostawał jeszcze do wykonania ogrom pracy związany z istniejącym wówczas systemem budowania opartym na autotools (automake, autoconf, libtool), aby przystosować go do Mac OS X.
Przejście KDE na system budowania SCons umożliwiło budowanie środowiska na platformie Mac, a przestawienie się na CMake – znacznie je ułatwiło. CMake odegrał znaczącą rolę w uproszczeniu kompilowania aplikacji KDE (zarówno GUI jak i konsolowych) dla innych platform bez zbytniego dodatkowego nakładu pracy ze strony programistów. Patrząc z punktu widzenia Linuksa, kompilacja na Mac OS X jest bardziej kapryśna i trudna do zrozumienia (zwłaszcza podczas tworzenia bibliotek ładowanych dynamicznie). Wykorzystanie CMake uczyniło ten proces bardziej przejrzystym. Jest tak dzięki wytężonej pracy Alexandra Neundorfa, która umożliwiła budowanie KDE za pomocą CMake. Przenoszenie aplikacji stało się tym samym łatwiejsze.
Podsumowując, było wiele technicznych trudności w zbudowaniu KDE niezależnego od X Window Sytem. Wiele z nich zostało przezwyciężonych dzięki pracy utalentowanych i oddanych ludzi. Pozostało już tylko kilka problemów do przezwyciężenia w przenoszeniu na Maca. Teraz skupiamy się głównie na rozwijaniu KDE 4 oraz usuwaniu drobnych błędów, zanim pociągną one lawinę większych problemów.

Jakie techniczne wyzwania stanęły przed programistami?

Jarosław

Integracja KDE z istniejącymi rozwiązaniami dostępnymi na docelowych platformach.
W niektórych przypadkach nie powinno być problemów z wykorzystaniem elementów konfiguracyjnych docelowych platform. Mam tu na myśli paski narzędzi Mac OS X czy Windows lub pewne właściwości zarządzania oknami (np. tryb pełnoekranowy, ang. fullscreen). Dzięki naszemu API, biblioteki KDE zawierają odpowiednie składniki, które zachowują się odpowiednio w każdym środowisku. Wiele z nich, jak choćby te dotyczące dostępności (ang. accessibility) jest dostarczanych przez Qt, więc programiści KDE mogą się skupić na przygotowywaniu bardziej złożonych funkcji.

Jakie były techniczne aspekty tworzenia KDE na Windows?

Jarosław

Na Windows wiele zależności nie jest postrzeganych w kategoriach bibliotek „systemowych”, więc musieliśmy je udostępnić w ramach tak zwanego środowiska programistycznego KDE. Środowisko to jest potrzebne jedynie programistom, a nie zwykłym użytkownikom. Główną regułą jest tutaj wykonanie możliwie jak najbardziej zwartego i samowystarczalnego środowiska programistycznego dla KDE, tak aby maksymalnie uczynić życie nowym programistom. Na Windows są używane dwa główne kompilatory gcc w wersji MinGW oraz MS Visual C++ (msvc). C++ nie określa binarnej zgodności między kompilatorami od różnych dostawców, więc dystrybuując binaria, będą też prawdopodobnie dystrybuowane biblioteki KDE dla obu kompilatorów.
CMake jest używany jako system budowania wyższego poziomu dla KDE 4, nadbudowany nad kompilatorami i specyfiką danego środowiska. Jest to pozytywna zmiana od czasu, gdy dla KDE3/Windows był wykorzystywany qmake nie dający szans na użycie bardziej zaawansowanej i zautomatyzowanej konfiguracji przed właściwą kompilacją. Dla przykładu, jeśli potrzebujesz, aby twoja aplikacja obsługiwała MySQL, teraz jest możliwe jednokrotne wpisanie odpowiednich warunków sprawdzających, po czym podczas kompilacji system będzie próbował znaleźć niezbędne składniki.
Związki KDE z firmą Trolltech są doskonale znane. W trakcie prac nad KDE 4, kooperacja społeczności z firmami stała się jeszcze ściślejsza, dla obopólnych korzyści. CMake, zaawansowane narzędzie do zarządzania budowaniem dużych programów zostało dostarczane przez firmę Kitware. Firma regularnie dostarcza kolejne wersje CMake wyposażane w funkcje niezbędne do rozwijania tak dużego projektu, jakim jest KDE.

Czy są jakieś szczególne wymagania dla Mac OS X?

Benjamin

Dla tej platformy nie ma żadnych specjalnych wymagań za wyjątkiem XCode (środowisko kompilacji firmy Apple oparte na gcc). KDE posiada bardzo wiele zależności, które muszą zostać spełnione. Jeśli nie chcesz spędzać wielu dni kompilując samodzielnie bibliotekę libpng, D-Bus, itp. to prawdopodobnie będziesz zainteresowany instalacją przygotowanych przeze mnie pakietów, które udostępniłem w sieci. Pakiety te zawierają nagłówki oraz biblioteki programistyczne, tak że można z ich pomocą kompilować KDE z repozytorium Subversion.

Jaka jest strategia dystrybucji?

Jarosław

W systemie Windows istnieje instalator, który instaluje środowisko programistyczne. Ostatecznie będzie wybór między wersją KDE dla zwykłych użytkowników oraz wersją dla programistów. Więcej o tej opcji można się dowiedzieć w wątku KDE Lists.

Benjamin

Na Macu łączę obecnie pakiety instalacyjne, z wszystkimi zależnościami w jeden instalujący się do katalogu /opt, aby zapobiec konfliktom z innymi programami. Moim celem jest dostarczanie KDE 4 poprzez repozytorium Fink, ale obecnie nie zajmuję się tym dopóki nie osiągniemy poziomu wersji beta. Nawet po tym etapie, będę pewnie kontynuować tworzenie instalatora pakietów. Większość jego elementów jest zautomatyzowana i dość łatwo jest zainstalować KDE 4 w systemie bez żadnych zewnętrznych zależności.

Jakie są terminy, dodatkowe opcje i przyszły rozwój projektu?

Jarosław

Terminy dla KDE/Windows są uzależnione od planów rozwoju KDE 4. Generalnie staramy się dotrzymywać kroku głównemu wydaniu KDE, czyli temu na platformie Linux/Unix. Jest pewna grupa ludzi (włączając mnie), która jest zainteresowana rozwojem oprogramowania komercyjnego z wykorzystaniem narzędzi oferowanych przez KDE na Windows. W ramach KDE jest rozwijany podprojekt KDE ISV. Społeczność bez wątpienia staje się coraz większa, zaś aktywna baza użytkowników na Windows przyczynia się do rozwoju całego KDE.

Ralf Habacker

Podzieliliśmy nasz projekt na dwa etapy:

1. KDE na Windows używa obecnego kodu źródłowego i podobnego sposobu pakowania oprogramowania jak na systemach uniksowych. Udostępniane są aplikacje, których przeniesienie nie wymagała dużego wysiłku. Ma to na celu pokazanie jak działa idea KDE oraz zaznajomienie użytkowników Windows z aplikacjami KDE. Na tym etapie podstawowe problemy wynikające z różnic pomiędzy systemami uniksowymi a Windows muszą zostać przezwyciężone.
2. Gdy zbierze się wystarczająca liczba programistów, będziemy mogli dokonać częściowego przeprojektowania wnętrza KDE/Windows, aby korzystały ze specyficznym dla Windows funkcji jak nazwane potoki dla szybszej komunikacji między procesowej. Postaramy się aby mieć możliwość uruchamiania aplikacji takich jak Konqueror czy KMail bez powoływania do życia wielu dodatkowych procesów w tle. Widzę to jako przeprojektowanie programów klauncher, kded oraz wtyczek kioslaves, aby były dostępne w ramach pojedynczych aplikacji. Jarosław poszedł właśnie tą drogą w przypadku Kexi.

Czy w trakcie pracy nasuwają się wam jakieś nowe rozwiązania?

Ralf Habacker

Obecna implementacja KDE została przygotowana w stylu systemów uniksowych, które są w pewnym stopniu odmienne od Windows. Oto kilka przykładów:

• tworzenie procesów – użycie uniksowego fork i exec,
• niektóre elementy nie są dostępne w Windows, co narzuca potrzebę przeprojektowania pewnych danych elementów KDE,
• brakujące odpowiedniki w windowsowym API – KDE wykorzystuje uniksowy niw występujące w Windows domain sockets do szybkiego przesyłania danych pomiędzy procesami w kioslave, a także do komunikacji z demonem D-Bus. Można skorzystać z emulacji przy pomocy gniazd TCP, ale odbędzie się to kosztem spowolnienia przepustowości oraz będzie wymagać poprawek w kodzie źródłowym.

Systemy różnią się interfejsami programistycznymi. Windows wprawdzie posiada podobny do uniksowego stos TCP, ale występujące różnice utrudniające przenoszenie aplikacji. Niektóre elementy wymagają nawet przepisania części kodu KDE.

Po opublikowaniu Qt 4 na licencji GPL naszym następnym zadaniem było stworzenie natywnej wersji bibliotek KDE 4 dla Windows. Głównym naszym problemem był brak rąk do tej dużej pracy (natywna implementacja D-Bus i uruchamianie całych aplikacji KDE, aby pokazuje jakich postępów dokonaliśmy). Staramy się publikować postępy naszych prac ponieważ liczymy na nowych programistów. Nie zapominajcie, że robimy to wszystko w naszym wolnym czasie.

——————————————–

Scott Ruecker

Peter Kümmel, Holger Schröder i Christian Ehrlicher to tylko niektórzy nie wymienieni wyżej programiści pracujący nad przenoszeniem środowiska KDE do Windows. Derek Ditch, Alexander Neuendorf, Marijn Kruisselbrink i Tanner Lovelace zajmują sie z kolei przenoszeniem KDE na platformę Mac OS X. Wymienione zostało tylko kilka osób, ale oprócz nich jest wiele innych zaangażowanych w te projekty. Ich praca potencjalnie zwiększy ilość użytkowników Wolnego Oprogramowania.
Wierzę, że przeportowanie KDE na Mac OS X i Windows będzie doniosłym momentem dla całego oprogramowania Open Source (OSS). Ludzie są niechętni zasadniczym zmianom, a moje doświadczenia z nimi nauczyły mnie wykorzystywania różnych sposobów na zachęcenie ich do używania Linuksa, np. uruchamiając LiveCD i pokazując później jak je zainstalować. Generalnie, staram się zastępować słowo „zmienić” słowem „dodatkowy”. Wtedy znacznie łatwiej przekonać kogoś do wypróbowanie oprogramowania Open Source. Jeśli „dodamy” KDE do Maca lub Windows wtedy miliony ludzi będą mogły je wypróbować. Jestem przekonany, że wielu z nich OSS się spodoba. Początki korzystania z KDE są łatwiejsze niż początki palenia ;-).
Od czasu, gdy pierwszy raz pobrałem i zainstalowałem Firefox nie słabnie moje uzależnienie od OSS. Zacząłem od Firefoksa i stopniowo przechodziłem na oprogramowanie OSS. Od dwóch lat używam tylko wolnego oprogramowania. Dlaczego? Dokonałem takiego wyboru porównując je do nie-wolnego oprogramowania podczas codziennego użytkowania. Nie zauważyłem pogorszenia jakości programów czy funkcjonalności lub bezpieczeństwa mojego komputera. Mało tego, po migracji do systemu Linux mój komputer funkcjonuje znacznie lepiej niż wcześniej w Windows. Jak to się stało? Zacząłem używać jednego programu, który tak mnie zafascynował, że nie było już dla mnie powrotu.
Niedługo każdy posiadacz komputera będzie mógł „dodać” do niego OSS, a następnie je wypróbować i używać. To nie powinno być trudne. Przecież ludzie dodają do swoich komputerów nowe programy codziennie. Powiedzmy, że 25 do 50 milionów ludzi, którzy nigdy przedtem nie korzystali z OSS, wypróbuje je. Wszyscy, którzy już wcześniej wypróbowali OSS wiedzą, co mam na myśli. Leżąc na łodzi, patrząc na ocean i widząc spiętrzenie wody zadajesz sobie pytanie: „Czy to zbliża się następna wielka fala?” Odpowiedź brzmi: „Tak, to zbliża się kolejna wielka fala”.

Poprawki tłumaczenia: Jarosław Staniek