W tym tygodniu było prowadzonych wiele prac wokół projektu Amarok m.in. związanych z implementacją w OpenGL nowej wizualizacji listy albumów o nazwie kodowej “CoverBling” oraz z
Markiem Kretschmann. Mark przedstawił stan prac prowadzonych w tym tygodniu przy projekcie Amarok, m.in. związanych z implementacją w OpenGL nowej wizualizacji listy albumów o nazwie kodowej “CoverBling”:

Wszyscy kochają iCukierki! Wierni użytkownicy Amaroka nie są wyjątkiem pod tym względem więc staramy się aby Amarok 2.0 był wyjątkowo piękny. Od czasu gdy Apple wypuścił nową wersję iTunes wraz z nową prezentacją listy albumów o nazwie CoverFlow wielu użytkowników prosiło nas o zaimplementowanie w Amarok 2.0 podobnej możliwości. Przyznając się, że jestem małym osiołkiem w sprawach grafiki komputerowej, postanowiłem pobawić się trochę tym pomysłem jakiś czas temu; dwa tygodnie temu zdecydowałem spróbować wprowadzić ideę w życie i pomimo tego, że nie kodowałem niczego związanego z grafiką od kilku lat to początkowy rezultat moich prac zachęcił mnie do dalszego trudu.

Rozpocząłem od prostego oteksturowanego prostokąta z możliwością robienia zbliżenia, by następnie dodać efekt refleksów, właściwą perspektywę widoku i możliwość przedstawienia kilku okładek i ich przesuwania w interesującym nas kierunku. Domyślnie wykorzystywany jest do tego pełnoekranowy antyaliasing, który pozwala na wyświetlanie obrazów w bardzo dobrej jakości.
Wczoraj zaimplementowałem wybór obiektów, co oznacza, że teraz jest prawidłowo wykrywane jest nad, którym obrazkiem zatrzymał się kursor myszy i dzięki temu również odpowiedniego reagowania. Następnie doszło do małej burzy mózgów między mną a Sebem Ruizem na temat projektu i mechanizmu nowej prezentacji listy albumów (o nazwie kodowej “CoverBling”). Zdecydowaliśmy, że nie chcemy tylko skopiować możliwości iTunes, co byłoby nie tylko lamerskie ale być może także naruszeniem praw autorskich. Zamiast tego chcemy zaprezentować coś równie odlotowego (a idealnie było by gdyby udało się nam nawet coś jeszcze bardziej odlotowego) ale i własnego. Jak na razie mamy ciekawe pomysły; zaczęliśmy od implementacji jednej z koncepcji Seba i chcemy zobaczyć jak nam to wyjdzie. Jeśli macie dobre pomysły to zespół programistów projektu Amarok chętnie ich wysłucha.

Rys1. Amarok 2.0

Z pozostałych wiadomości dotyczących Amaroka mogę poinformować o naszych rozważaniach nad wykorzystaniem Plasmy do widoku kontekstualnego (w obecnych pracach widoczny w środkowej części okna aplikacji). Posunięcie to zostało zainicjowane przez Leo Franchi współpracującego z nami w ramach festiwalu Google Summer of Code. Leo rozpoczął prace nad nową, eksperymentalną gałęzią w repozytoriach SVN przeznaczoną dla integracji z projektem Plasma a ja osobiście czekam z niecierpliwością na pierwsze rezultaty. Utworzenia nowej gałęzi oznacza również, że większości dotychczas napisanego kodu dla widoku kontekstowego zostanie wyrzucona a przez co wymagane jest na nowo jego przepisanie. Drugą stroną medalu są wielkie możliwości jakie daje Plasma - dodawanie plasmoidów będących skryptami, wykorzystanie zaawansowanej grafiki wektorowej jako format SVG oraz zdolność do tworzenia motywów. Nie musimy też przez to “wymyślać na nowo koła” (albo roweru jak lubimy sobie żartować) lecz po prostu konsultujemy nasze działania z programistami projektu Plasma. Wykorzystanie Plasmy może również przysporzyć problemów technicznych; biblioteka libplasma musi zostać trochę zmieniona by można było ją wykorzystać w Amaroku; Leo już przygotował odpowiednią łątkę na libplasma, którą chcielibyśmy aby została na stałe dodana do biblioteki. Na tym etapie chcielibyśmy zaapelować do Aarona Seigo (przyp. red. programista zarządzający projektem Plasma): proszę, skontaktuj się z nami!
Podsumowując - myślę, że mamy przed sobą bardzo ekscytujący czas prac nad Amarokiem 2.0 a najlepsze dla mnie w tym wszystkim jest powrót motywacji do implementowania nowych możliwości odtwarzacza jaki przyszedł wraz z moimi próbami programowania przy wykorzystaniu OpenGL. Przecież zawsze na końcu okazuje się, że chodzi tylko o motywacje, czyż nie tak?

Boudewijn Rempt uaktualnił listę ostatnich zmian w Kricie:

Ostatnie prace Emanuele Tamponiego są naprawdę całkowicie odlotowe - oto mamy kogoś, komu się chciało przebrnąć przez całą tą dokumentację akademicką, przeczytać i wypunktować podstawowe zagadnienia a na sam koniec stworzyć unikatowe oprogramowanie, które po prostu jest pierwszym dostępnym na taką skalę.
Obecna praca Emanuele, w miksowaniu kolorów z wykorzystaniem teorii Kubelka-Munk o odbiciach pigmentów, pozwalają na malowanie w sposób tak naturalny i prosty jak nigdy przedtem.
Z innej beczki: Sven Kangkamp pracuje na selekcjami, które nie są tak widowiskowe, ale w chwili gdy wszystko zaczęło działać tak jak użytkownicy odczuwają, że powinno wydaje się być to ważnym udogodnieniem. Kiedy oprogramowanie zmienia się z “działającego nieprzyjemnie” w “o! udało mi się to wykonać i odpaliłem przy tym Kritę” to ostatnie “o!” może nie jest śmiałe, ale robi dużą różnicę w odczuciach użytkownika.
Z drugiej, mniej przyjemnej strony; mieliśmy mały rozgardiasz w tym tygodniu związany z naszą implementacją metadanych, ale na szczęście zostało to już rozwiązane i posuwamy się dalej. Krita dalej będzie dawać czadu a zamieszanie wokół metadanych się skończyło. Cyrille Berger, jeden z naszych bardziej płodnych i wszechstronnych koderów postanowił nie obciążać mnie zadaniem implementacji metadanych (a także związanych z nimi wsparciem dla EXIF i XMP) i sam już zrekonstruował kode. Berger zamierza kontynuować prace, ale dyskusje na temat implementacji będzie tylko prowadził z osobami znających się na rzeczy. Czasami programista potrzebuje odrobiny spokoju by stworzyć wspaniałe oprogramowanie.
Osobiście uważam, że Cyrille jest bardzo dobrze wykwalifikowanym do pracy w tej sferze a od kiedy powiedział, że już udało mu się osobiście przeprowadzić rozmowę (a przy tym owocną i pełną wniosków) z programistami projektów Strigi i NEPOMUK zawierzam mu całkowicie to zadanie.
Ostatnio Krita została opisana w Linux Journal. Autorzy artykuł o Kricie ocenili aplikacje bardzo pozytywnie, zwłaszcza w świetle drobnych zastrzeżeń (a dokładniej związanych z narzędziem tekstowym), które udało się już poprawić w przyszłym wydaniu (w gałęzi trunk) - dzięki pracom Thomasa Zandera i Cyrille Berger.

Richard J. Moore zaproponował usunięcie silnika JavaScript - KJSEmbed - z bibliotek KDELibs:

Po dyskusjach przeprowadzonych podczas tegorocznego aKademy chciałbym zaproponować usunięcie KJSEmbed z bibliotek kdelibs przed wydaniem KDE 4.0. Obecna funkcjonalność KJSEmbed jest duplikowana przez QtSCript i wydaje się bezcelowe nasze dalsze zarządzanie projektem KJSEmbed w sytuacji, gdy mamy dostępne rozwiązanie dostarczone przez Trolltech, które potrafi wykonywać te same zadania tak samo dobrze. By dobrze zrealizować usuwanie KJSEmbed należy wykonać kilka czynności:

1. Usunąć KJSEmbed jak i wsparcie dla KJSEmbed w Kross. Można to wykonać do 25 lipca
2. Dodać wsparcie dla QtScript w Kross (przyjrzałem się wtyczce KJSEmbed i napisanie ekwiwalentu dla QtScript wydaje się rzeczą prostą). To też najprawdopodobniej można zrobić do 25 lipca.
3. Załączyć wtyczki do kdelibs, które rozszerzałyby funkcjonalność QtScript o brakujące elementy. Wykonanie tego będzie trudne do 25 lipca ale może zostać pominięte (albo też wykonane w oddzielnym terminie jeśli będzie taka potrzeba). Udało mi się już zaimplementować podstawę wtyczek, także skrypty pozwalają już na tworzenie okien dialogowych i wykorzystywać pliki opisu interfejsów graficznych; uważam jednak, że API obecnie dostarczone dla skryptów potrzebuje jeszcze trochę przemyśleń.

Szczegóły dotyczące tych zmian przedstawiłem podczas prezentacji na aKademy.