Wywiad z twórcą Amaroka 2.0 - Jeffem Mitchellem

Wywiad przeprowadziła Amara Emerson 14.06.2007.

W drodze ku KDE 4, Amarok będzie ulegał dużym zmianom - zarówno wewnętrznym jak i kosmetycznym (w interfejsie użytkownika). Przeprowadziłam wywiad z programistą Jeffem Mitchellem, rozmawialiśmy o tych zmianach w Amaroku od stabilnego wydania 1.4 do wersji 2.0, włączając nowy układ playlisty, widok kontekstowy oraz nową bibliotekę dla serwisów sieciowych. Zapraszam do lektury.

Amara Emerson: Amarok jest flagowym odtwarzaczem audio KDE i Linuksa. Jakie jest Twoje zdanie o jego wyróżniającej się pozycji wśród innych podobnych programów?

Jeff Mitchell: Myślę, że ma na to wpływ kilka rzeczy. Jedną z nich była koncepcja funkcjonalnej „przeglądarki”, która kiedyś programowi unikatowy charakter, a dzisiaj ciągle wyróżnia go w wielu aspektach. Zamiast próbować zbudować jeden interfejs, który mógłby obsługiwać więcej i więcej i więcej elementów, podzielono je w logicznej przeglądarce, której komórki zapewniają potrzebną funkcjonalność: dostęp do playlisty, ustawień muzyki, przeglądania kolekcji, itd. Ponieważ możesz łatwo zamienić całą część interfejsu graficznego na całkowicie nową, dostarczającą nowych funkcji, całość pozostaje przejrzysta i poukładana. Poza tym Twoja muzyka jest zawsze pod ręką, ponieważ playlista została wyeksponowana.

Innym elementem, który nas wyróżnia jest innowacyjność. Analizowaliśmy nasze błędy oraz rozwiązania znane z innych odtwarzaczy, podpatrywaliśmy niektóre pionierskie koncepcje, ale elementy naszego programu były wciąż unikalne. Takim jest np. radio Last.fm, które Amarok udostępnił jako pierwszy. Od dawna był obsługiwany streaming MP3 oraz system Scrobbling songs więc gdy powstało Last.fm jego udostępnienie było rzeczą naturalną.

System dynamicznej kolekcji (z tego co wiem) wciąż jest dostępny tylko w Amarok, a jest to istotna funkcja dla mobilnych użytkowników, którzy przechowują swoją muzykę na laptopach, które czasem są podłączone do innych nośników, a czasem nie. Przedtem musiałeś przeszukiwać inne nośniki za każdym razem, gdy je podłączałeś; teraz Amarok po prostu wie, kiedy taki nośnik nie jest zamontowany i przechowuje informacje do czasu gdy nośnik znów będzie dostępny.

Funkcja śledzenia plików także była dostępna najpierw w Amarok, a później przeniesiona do innych odtwarzaczy. Jest ona ściśle zintegrowana z wieloma częściami programu i działa bardzo dobrze.

Na koniec chciałbym podkreślić, że bardzo liczymy się z naszymi użytkownikami i społecznością, jesteśmy na nich otwarci. Każdy pomysł podnoszony przez użytkowników jest rozważany, a większość dobrych idei jest implementowana jeśli nie pociąga za sobą zasadniczych, destrukcyjnych zmian w kodzie źródłowym. Staramy się to zrównoważyć tak, że nasza aplikacja wciąż jest prosta dla nowych użytkowników, a jednocześnie staje się coraz potężniejsza dla stałych fanów i miłośników muzyki.

Czy jest dużo zmian podczas przenoszenia programu z Qt 3 na Qt 4, co wymaga najwięcej wysiłku i czasu, implementowanie nowych możliwości/nowego interfejsu graficznego czy przenoszenie istniejącego kodu?

Jak powiedziałem, implementowanie nowych funkcji jest czymś więcej niż tylko wytapianiem czasu. Qt posiada wsteczną kompatybilność, która prowizorycznie działa do czasu, aż kod źródłowy nie zostanie przeniesiony, więc samo uruchomienie Amarok na Qt 4 nie zajęło zbyt dużo czasu. Wiele z nieprzeniesionych elementów nie było zmienianych ponieważ zostaną zastąpione nowymi. Tak więc poświęcamy nasz czas nowym funkcjom i możliwościom. Według nas jest to właściwe postępowanie, bo mamy wiele pomysłów i wielkie plany.

Jak wielką rolę w stabilnym wydaniu Amarok odgrywają języki skryptowe takie jak Ruby? Czy ich rola w wydaniu 2.0 będzie większa czy mniejsza?

W wydaniu stabilnym języki skryptowe były używane w niewielu funkcjach. Pierwsze były wtyczki. Nie dopuszczamy wtyczek pochodzących od zewnętrznych autorów, ale poprzez DCOP oferujemy ogromną liczbę funkcji dla wtyczek skryptowych w stabilnym wydaniu Amarok. Menadżer skryptów Amaroka byłby w stanie uruchomić je i wykorzystać, gdyby zaistniała taka potrzeba.

Inną zasadniczą funkcją skryptów było pośredniczenie. Dla wielu usług nie ma dobrego rozwiązania pozwalającego otrzymywać potrzebne dane, np. dla obsługi Last.fm Amarok miał skrypt w języku Ruby, który działał jako pośrednik w obsłudze połączenia internetowego i w ten sposób przekazywał otrzymane dane do silnika programu. Wiem, że dzięki zmianom w API Last.fm to rozwiązanie nie będzie już potrzebne w Amarok 2.0. Także DAAP jest usługą, którą Amarok obsługuje dzięki użyciu skryptów w Ruby w celu zapewnienia połączenia z klientami. Języki skryptowe są wykorzystywane ponieważ można komunikować się przez HTTP w trochę łatwiejszy sposób niż gdybyśmy kodowali to wszystko w C++.

W Amarok 2.0 wtyczki skryptowe nadal będą używały języka skryptowego, chociaż teraz będą wykorzystywały DBus zamiast DCOP. Nie jestem do końca pewny w jakich innych celach będą jeszcze wykorzystywane języki skryptowe.

Tak pokrótce, jakie zasadnicze zmiany będą dokonane w wersji 2.0?

Wersja 2.0 przyniesie zasadnicze zmiany w Playlist. Amarok nigdy nie był przeznaczony do obsługiwania ekstremalnie dużych list; ideą zawsze było przeglądanie i przeszukiwanie Twojej kolekcji muzyki przez wskazanie lub dynamiczną playlistę. W tym samym czasie ta playlista stawała się wielka, a w rezultacie czego mamy skargi od użytkowników, którym bardzo powoli działa samo otwieranie listy z ponad 6 tysiącami skolejkowanych utworów. Do tego masz ograniczoną ilość miejsca na ekranie, aby umieścić wszystkie potrzebne informacje. Z tego powodu funkcja playlista w Amarok 2.0 jest przygotowana tak aby lepiej pokazać informacje o obecnym i następnym utworze, podczas gdy będzie zniechęcać do wielkich, długich playlist.

Prosta playlista działa już teraz bardzo dobrze, podczas gdy playlista dynamiczna używająca tej pierwszej jako źródła, pozwala tylko na losowy dobór utworów. Prawdopodobnie będą one ulepszone, aby lepiej wypełnić nowy model playlisty. Do innych nowości w Playlist należy, w co wierzę, krótsze kolejkowanie utworów. Kolejkowanie jest obecnie całkiem przyjemne, jednak niektórzy uważają je za mało intuicyjny sposób gromadzenia utworów w playlistę, za wyjątkiem tych, które są skolejkowane po to, by odtworzyć je w kolejności jako pierwsze... myślimy o nowym uporządkowaniu playlisty, który nie będzie wymagać użycia oddzielnego kolejkowania.

Następne wielkie zmiany zawiera widok kontekstowy. Nie jest on już tylko przeglądarką - zaplanowano go jako obszar zawierający widżety zamiast renderowanego HTML, który w końcu będzie ograniczała się do tego, co chcemy pokazać i obsługiwać. Nasze usługi sieciowe zostaną zasadniczo popchnięte do przodu – przygotowujemy całą bibliotekę, aby później łatwo dodawać dowolne usługi sieciowe, serwisy sprzedające muzykę, teksty utworów, tabulatury gitarowe, informacje o koncertach, itp.

Duża praca została również wykonana w systemie kolekcjonowania. Meta-informacje, które znajdowały się w różnych elementach programu Amarok zostały ukierunkowane i streszczone. W rezultacie będziemy mieć obsługę wielu kolekcji różnych typów – usług sklepów internetowych jak MP3Tunes, przenośnych odtwarzaczy, kolekcji SQL (lokalnych plików) – będzie można bezproblemowo kolejkować i odtwarzać muzykę ze wszystkich lub wybranych źródeł.

Na koniec, urządzenia będą obsługiwane przez Solid. Wykonaliśmy też pracę razem z autorami bibliotek i oraz programistami HAL, aby mieć pewność, że gdy urządzenie jest włączone (prawdopodobnie z zainstalowanymi niezbędnymi bibliotekami), Amarok będzie umiał je wykryć i z nim pracować. Nie mam na myśli urządzenia, które po prostu nie chce pracować w Linuksie.

Oh, a wspomniałem o portach na Maca i Windows?

Amarok 1.x jest zależny od bibliotek KDE (kdelibs). Czy ta zależność będzie też w wersji 2?

Tak, ciągle zależymy od kdelibs. Myśleliśmy o przejściu na zależność tylko od Qt, głównie po to by umożliwić działanie aplikacji na Maca i Windows, ale teraz, gdy kdelibs jest przenoszone na te platformy, nie widzimy już wielu korzyści z ograniczenia się do Qt. W efekcie nastąpiłaby utrata pewnych funkcji i zgodności z bibliotekami KDE, przygotowywanymi również dla nas. Wobec tego, kdelibs, w czasach gdy przestrzeń dyskowa jest duża, jest dość zwartym komponentem. Nie jest zbyt wielkim problemem dla tych, którzy preferują Gnome czy inne środowiska.

Wcześniej wspomniałeś o bibliotece dla usług sieciowych. Domyślam się, że pozwala dodawać nowe serwisy, jak Magnatune. Mógłbyś to rozwinąć?

Gdy dodaliśmy obsługę Magnatune, wiele niezależnych, podobnych serwisów zgłaszało się do nas, prosząc by dodać podobną obsługę także dla nich. Jeden z naszych programistów oraz uczestnik SoC (Summer of Code) obecnie starają się sformalizować standard API dla muzycznych sklepów online, aby mieć pewność, że wszystkie będą miały taką samą jakość obsługi (!). Takie sklepy są dla nas dobre, bo jeśli za utwory kupowane za pomocą Amarok dostaniemy ułamek ich ceny, to pieniądze te wrócą do projektu i będziemy mogli pokryć różne wydatki (nie trafią do kieszeni żadnego z programistów). Nawet jeśli nie uda się zbudować takiego wspólnego API, to i tak powstanie dość dobra biblioteka usług sieciowych. Jeśli się nie mylę, razem z nowymi metadanymi i infrastrukturą kolekcji już teraz biblioteka ta obsługuje więcej niż tylko serwisy sprzedające muzykę – podstawową obsługę mają też Jamendo (serwis z darmową muzyką umieszczaną tam przez jej autorów) i Oboe MP3Tunes. Dodawanie nowych, różnych informacji czy źródeł muzyki powinno być coraz prostsze i bardziej dojrzałe. Obecnie sprawdzamy dostarczanie innych informacji (oczywiście poza tekstami utworów i Wikipedią), takich jak tabulatury gitarowe i informacje o koncertach.

Skomentuj ten artykuł na forum KDE »

Ten artykuł jest tłumaczeniem tekstu Amarok 2.0 Interview: Jeff Mitchell z serwisu dot.kde.org.