W tym tygodniu tłumaczenie wywiadu z Jeffem Mitchellem jednym z developerów programu Amarok.

Wywiad przeprowadziła Amara Emerson 14 czerwca 2007 roku. Oryginalny tekst znajduje się na stronach dot.kde.org Amarok 2.0 Interview: Jeff Mitchell

W drodze do KDE 4, Amarok będzie ulegał wielkim zmianom, zarówno „pod maską” jak i w interfejsie użytkownika. Przeprowadziłam wywiad z developerem Jeffem Mitchellem, rozmawialiśmy o zmianach w Amaroku od stabilnego wydania 1.4 do wersji 2.0, włączając nowy układ playlisty, widok kontekstowy oraz nowy framework serwisów sieciowych. Zapraszam do lektury.

Amara Emerson: Amarok jest flagowym odtwarzaczem audio KDE i Linuksa. Jakie jest Twoje zdanie na temat 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ś stworzyła unikatowy charakter programu, a dzisiaj ciągle wyróżnia go w wielu elementach. Zamiast próbować zdefiniować 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, ustawiań muzyki, przeglądania kolekcji itd. Ponieważ możesz łatwo zamienić całą część UI na totalnie nową, która dostarczy nowych funkcjonalności, utrzyma to wszystko przejrzyste i poukładane. Dodatkowo, twoja muzyka jest zawsze na widoku kiedy playlista jest eksponowana.
Innym elementem, który nas wyróżnia jest innowacyjność. Przeglądaliśmy nasze błędy oraz rozwiązania innych odtwarzaczy, podpatrywaliśmy niektóre pionierskie koncepcje, ale nasze elementy były wciąż unikalne. Żeby nazwać kilka, Amarok jako pierwszy udostępnił radio Last.fm. Od dawna był wspierany 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, ale przechowuje informacje do czasu gdy będzie.
Śledzenie plików także było pierwsze w Amarok (później przeniesione do innych odtwarzaczy). Jest ono ściśle zintegrowane z wieloma częściami programu i działa bardzo dobrze.
Na koniec chciałbym podkreślić, że zwracamy dużą uwagę na naszych użytkowników i społeczność, jesteśmy na nich bardzo 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. Staramy się to wypośrodkować tak aby nasza aplikacja wciąż była łatwa dla nowych użytkowników, a także stawała się coraz potężniejsza dla stałych fanów i miłośników muzyki.

Amara Emerson: Czy jest dużo pracy podczas przenoszenia programu z Qt3 na Qt4, co wymaga najwięcej wysiłku i czasu, implementowanie nowych możliwości/nowego UI czy portowanie istniejącego kodu?

Jeff Mitchell

Jak powiedziałem, implementowanie nowych cech jest czymś więcej niż tylko wytapianiem czasu. Qt posiada wsteczną kompatybilność, która prowizorycznie działa do czasu, aż kod nie zostanie przeportowany więc samo uruchomianie Amarok na Qt4 nie zajęło zbyt dużo czasu. Wiele z nie przeniesionych elementów nie było zmienianych ponieważ zostaną zastąpione nowymi. Tak więc nowe funkcje i możliwości są tymi elementami, na które poświęcamy nasz czas, i to jest właściwe postępowanie, bo mamy wiele pomysłów i wielkie plany.

Amara Emerson: 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?

Jeff Mitchell

W wydaniu stabilnym języki skryptowe były użytkowane w niewielu funkcjach. Pierwsze były wtyczki. Nie dopuszczamy wtyczek „third-party”, ale przez DCOP pokazujemy ogromną liczbę funkcji wtyczek skryptowych oraz sposobów ich użytkowania w stabilnym wydaniu Amarok. Amarok Script Manager byłby w stanie uruchomić je i wykorzystać gdyby zaistniała taka potrzeba.
Inną zasadniczą funkcją było zachowanie wobec proxy. Dla wielu usług nie ma dobrego rozwiązania, aby otrzymać potrzebne dane. Dla przykładu dla Last.fm Amarok miał skrypt w Ruby, który działał jako proxy do obsługiwania połączenia internetowego, który dopuszczałby później dane do odtworzenia do silnika. 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 wspiera dzięki użyciu skryptów w Ruby. Języki skryptowe potrafią wysyłać i odbierać dane za pośrednictwem protokołu HTTP, co jest potrzebne do zapewnienia połączenia z innymi klientami. Oczywiście można by było zapewnić taką funkcjonalność w C++, jednak takie rozwiązanie jest prostsze.
W Amarok 2.0 wtyczki skryptowe ciągle 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.

Amara Emerson: Tak pokrótce, jakie zasadnicze zmiany/cechy będą dokonane w wersji 2.0?

Jeff Mitchell

Wersja 2.0 przyniesie zasadnicze zmiany w playliście. Amarok nigdy nie był przeznaczony do obsługiwania ekstremalnie wielkich list, ideą zawsze było przeglądanie i przeszukiwanie twojej kolekcji muzyki przez wskazanie lub dynamiczną playlistę, ale w tym samym czasie ta playlista była wielkim przeglądem, który pokazywał wiele utworów naraz oraz samoczynnie przemieniał się w długą playlistę. W rezultacie mamy skargi od użytkowników, którym bardzo powoli działa samo otwieranie listy ponad 6 tys. skolejkowanych utworów. Do tego masz ograniczoną ilość miejsca, aby umieścić wszystkie potrzebne informacje. Z tego powodu funkcja Playlist w Amarok 2.0 jest przygotowana 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 dynamiczna, która używa tej pierwszej jako źródła, pozwala tylko na losowy dobór utworów. Prawdopodobnie będą ulepszone, aby lepiej wypełnić nowy model Playlist. Z innych nowości w Playlist, wierzę, że kolejkowanie utworów będzie krótsze. Jakkolwiek kolejkowanie jest całkiem przyjemne, niektórzy uważają za mało intuicyjne gromadzenie 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 Context View. Już nie jest tylko przeglądarką, zaplanowano go jako scenę front-and-center zawierającą widżety zamiast renderowanego HTML, która w końcu będzie ograniczała się do tego, co chcemy pokazać i obsługiwać. Nasze usługi sieciowe zostaną zasadniczo popchnięte – przygotowujemy cały framework, aby później łatwo dodać dowolne usługi sieciowe, serwisy sprzedające muzykę, teksty utworów, tabulatury gitarowe, informacje o koncertach itp.
Wielka praca została również wykonana w systemie kolekcjonowania. Meta informacje, które znajdowały się w różnych elementach Amarok zostały ukierunkowane i streszczone. W rezultacie będziemy mieć wsparcie dla 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 kolejkować i odtwarzać muzykę ze wszystkich lub wybranych źródeł bezwiednie.
Na koniec, urządzenia będą obsługiwane przez Solid. Wykonaliśmy też pracę razem z developerami bibliotek i developerami 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?

Amara Emerson: Amarok 1.x jest zależny od kdelibs. Czy ta zależność będzie też w wersji 2?

Jeff Mitchell

Tak, ciągle zależymy od kdelibs. Myśleliśmy o przejściu tylko na Qt, głównie dla umożliwienia portowania na Maca i Windows, ale teraz, gdy kdelibs jest przenoszone na te platformy nie widzimy wielu profitów w utracie cech i zgodności z bibliotekami KDE, przygotowywanymi również dla nas. Także kdelibs, w czasach dużych przestrzeni dyskowych, jest dość dobrze samowystarczalne; to nie jest wielki problem dla tych, którzy preferują GNOME czy inne środowiska.

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

Jeff Mitchell

Gdy dodaliśmy wsparcie dla Magnatune wiele niezależnych, podobnych serwisów próbowało nas podejść, aby dostarczyć podobne wsparcie także dla nich. Jeden z naszych developerów i 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 takie samo wsparcie (!). 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 developerów). Nawet jeśli nie uda się stworzyć takiego wspólnego API to i tak powstanie dość dobry framework usług sieciowych, i jeśli się nie mylę, razem z nową meta-informacją/infrastrukturą kolekcji już teraz wspiera więcej niż tylko serwisy sprzedające muzykę – Jamendo (serwis z darmową muzyką umieszczaną tam przez jej autorów) i Oboe MP3Tunes oba mają już podstawowe wsparcie. 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.