freespirit

Over the last months, there has been a number of questions about the reason for the large empty space in the center of Amarok 2. I completely agree that having only a "Now Playing" applet there makes it seem kind of useless. The reason that we have not had much to show so far, has not been lack of ideas, but rather that many of the things we want to do requires the ability to do proper html rendering in a plasma applet, something that is just not possible with Qt 4.3.

So, hearing good things about the features that will be included in Qt 4.4, such as Widgets in QGraphicsView and QWebKit, I decided to setup a new development user and build KDE4 and Amarok 2 against the Qt 4.4 Technology Preview 1 to see what is possible.

After an hour or so of tinkering, I had this:



Now, this is not laid out properly, the svg background for the service info applet is horrible ( something I drew up in 5 minutes a looong time ago ) and the white background clashes with the svg colors, but all that will be fixed. The main point is that it is showing properly rendered html!!! This means that I can get rid of the annoying little info window at the bottom of the browser and use the full height to show browsable content. It also gives a sense of what the context view is all about.

This should allow us to start working on applets for Wikipedia info, lyrics, service info and many other things that, until now, has not been possible for us to do.

We have started a git repository for playing around with Qt 4.4, but for the time being, the svn trunk will remain Qt 4.3 to allow Amarok 2 to build on top of KDE 4.0.0 and 4.0.1.

As Shanes blog is not yet on the planet, I though I would forward this as I think it is a quite important announcement.

http://amarok.kde.org/blog/archives/583-Windows-Binaries-of-Amarok-2-Tech-Preview.html

Because I was a bit bored today and really felt like doing something new, and inspired by the quite large thread on podcasts on the Amarok mailing list, I sat down and wrote a simple podcast directory service on top of the service framework.

Right now, it does not really do anything besides showing stuff, but making it subscribe to the podcasts should be relatively simple, and will tie in really well with all the cool stuff Bart is doing with regards to podcast support in the playlist browser. Also, because of the flexibility of the service framework, filtering worked right away. The service is currently hardcoded to use an OPML file from http://www.digitalpodcast.com, but the plan is to make that configurable, or even to allow several at once ( like the Ampache service ). There are currently somewhere around 15000 podcasts listed at digitalpodcast.com, so it seemed like a good place to start.

So, to keep it short and sweet, here are some screenshots of what I have got so far:

In my last entry, I introduced the new svg theme "Graywolf" which was, as the name implies, quite gray. I also stated that one of the ideas behind this theme was to allow the application to automatically tint the svgs to match the system color scheme and that to achieve this, we needed a base them that did not have any single dominant colors. As some people were expressing doubts about the feasibility of this approach, I did what I always do in those situations: I came up with a quick and dirty prof of concept.

So, before I overwhelm your sense with an explosion of color, please remember that this is the result of one night of prototyping and some of the svgs are not tinted yet as I am waiting for an updated version ( the sidebar buttons, play controls, ... ). Also, work needs to be done to ensure adequate contrast in very light color schemes. The only thing different between the following screenshots is that I have changed the users color settings. No configuration at all has changed in Amarok itself. Of course I also choose some of the more, uhm... colorful, color themes to really illustrate the concept:










I actually think the black one is pretty sweet, even if the other ones are a bit "over the top" for my taste! .-)

It is still a work in progress and needs a lot of tweaking, but i hope this will put to rest some of the fears people have expressed that it is impossible to make svg graphics match the system color scheme.

In collaboration with Lee Olson, I have been trying to come up with a new svg theme for Amarok 2 with the working title of "Graywolf".

The main issue we are facing is that Amarok 2, being cross platform, will run on a multitude of different setups each with their own look and color scheme. Unfortunately, this makes it very hard to do svg files that will look good on all platforms, as the colors might be way off.

This new theme attempts to address this by not using very much color at all in the basic svgs. The current idea is to attempt to programatically tint these svgs with the dominant color scheme color, if it is very pronounced ( and non gray ).

The really great thing about this new theme is, that for the first time, we actually have a set of svgs that all look like they belong together. And even though the theme itself does not have much color, Amarok 2 will most likely not be dull as there will be context applets and album covers shown all over the place.

Anyway, I just finished the very initial integration of Lee's new svgs and added some supporting code, and thought I would show it off, even though it still needs quite a bit of work.

And yes, I know some of you will notice right away, but I am having issues with anti aliasing under KDE4 at the moment, so a lot of the text looks like crap!


So without further ado, I give you, "Graywolf"

Its official. I am going to be giving a talk at OpenExpo in March about the work I have been doing on integrating Free Culture and Open Music services into Amarok2 and how this collaboration benefits both the Free Software and Free Culture communities. I am super exited about this as this will be my first major conference appearance and I am really looking forwards to that. ( well, I might make an appearance in the KDE dev-room at FOSSDEM, which will most likely be the same talk, so you can get a sneak peak there if you are so inclined... )

I will be speaking on the technology track, the full program of which can be found here.

So now I actually have to start thinking about writing the talk...

One of the things that I have known for a while had to be done, but I had not really gotten around to, was making proper configuration pages for some of the services. For instance, having to type your mp3tunes username every time you want to use the mp3tunes service or the new ampache service. Also, it should be possible to disable services that are not used. With the recent conversion of all the services to proper plugins, I decided that it was time to start looking at this.

First of all, the neat KPluginSelector widget gives us an easy way of showing available plugins and enabling or disabling them. This makes it simple for each user to have only the plugins that are interesting to him or her shown in the service browser, and allows us to ship a large number of plugins without having to worry about the service browser becoming overcrowded. Then the only big question becomes which services to enable per default. For now, I have settled on Jamendo, Magnatune and Shoutcast. The reason for this choice is, that these are the current services usable by any user right away without requiring a account on some external server. Here is first a screenshot of the main service config page:



In this screenshot is also shown the new last.fm service that Shane King has just started working on.

For now I have written config pages for 3 of the services. Ampache, Mp3tunes and Magnatune.


The Ampache config allows configuration of any number of ampache servers, and a service will be created for each in the service browser:



For now, the only config options for the Mp3tunes service is simply to store the username and password so the service can connect automatically next time it is shown:



For the Magnatune service, I added experimental support for the upcoming Magnatune memberships. These memberships are not available just yet, but will be soon. In fact, getting these memberships ready for launch constitutes most of my day job these days. When this is done I will get to spend some real time getting Amarok2 ready:


All in all, these config options go a long way towards making many of the services more useful and less like the "developer toys" they have been for a while.

Anyone who reads any of my blog posts should know by now, that I am quite enthusiastic about Amarok2. I think our initial release, Amarok 2.0, is going to push the boundaries of what a music manager is, and how it can integrate with some of all the great internet services out there.

In this post I want to touch on something else that I have been thinking about in the last few weeks. Something that actually gets me just as exited, and that is Amarok2 as a technology platform.

This discussion has been raging in KDE4 land for a while, and the point that is often brought up is that KDE 4.0 is not all of KDE4. KDE 4.0 will be the very first version of KDE built on the KDE4 technology platform. In itself it is looking to be a interesting release, but the true potential of the underlying technology will only start to become fully realized in later KDE 4.x releases.

The same logic can be applied to Amarok. Amarok 2.0 will be a great release, built on top of some very interesting new technologies, but the full potential of these will not show through in the first release.

So what are these cool technologies that I keep going on about, and what kind of features do I envision in the future for Amarok 2.x ? First of all, I think the new collection framework by Maximilian Kossick is absolutely fantastic. It is the basis of everything we are doing in Amarok2. The local collection, portable media players and all the services are all built on top of this framework. This means that some of the neat tricks that the collection framework has up its sleeve will work for all of these. One of the really cool things that is possible with the collection framework is seamlessly moving and copying content between collections ( subject of course to some collections being read only ). In Amarok 2.0 this will be used for moving content between mobile devices and the main collection, but in the future, this could be expanded to allow things like full synching with mp3tunes, buying directly from magnatune.com to any other (writable) collection, syncing up an ampache server and mp3tunes or migrating to or from mp3tunes and any other similar service. These are just some of my ideas, and I am sure that you can dream up other ruses for this. This will also allow one of our most requested features, multiple collection support, to be implemented without compromising the design of the application.

Then there is the new Plasma based context view. While we have had little to show lately, this allows for some really nice and innovative content to be dynamically displayed. And since it is easily customizable, potentially users will be able to mix and match their own context information based on their current task.

And of course, my own pet project, the service framework which makes it easy to add new content to Amarok. It is my hope that this will attract new developers to Amarok who are interested in adding or improving services. This has actually already started to happen, with Casey Link stepping up to add album cover support to the mp3tunes service, and ending up doing all sorts of interesting work towards allowing full mp3tunes synchronization. Also, as our user base grows, it becomes more interesting for additional companies and online services to have their content added and support Amarok in one way or another. And as the services are quite independent from Amarok itself (they are now implemented as proper plugins ) there is little danger of any one company gaining too much control over Amarok, and Amarok will never become Dependant on any one service.

That is all for now. In recap, Amarok 2.0 will be great, but we have many cool ideas for 2.x that are now possible thanks to the new technological underpinnings!

This week something cool happened. Ok, something cool happens every week in Amarok land, but this week was something special.

We teamed up with Karl Vollmer, lead developer of the very cool Ampache music server to create an Ampache service for Amarok2. This is extra cool, as for the other services, I have relied on an already existing API to code against, but in this case, the API for accessing the Ampache content was developed in parallel with the service that uses it. Karl and I had been discussing doing this integration for a while, but the other day I decided that the Amarok framework for painlessly creating this service was in place, and Karl jumped on the idea, coding up the new API in record time.

Below is a screenshot of this in action:



In this screenshots there is also a number of other recent improvements visible, but I will leave it as a exercise for the reader to spot as many of these as possible.

The new Amapche API is of course not Amarok specific, but usable by any application that wants to provide a frontend for an Ampache music server, so this will benefit everyone. I just got word that the API has been checked into the Ampache svn and the docs can be found here

Big thanks to the Ampache team for making this possible!

Yesterday I had a few hours on my own, and since I had nothing better planned, I decided to actually implement one of the things that I have been meaning to do for a long time. Originally, I had planned to somehow use libktorrent to handle downloading of albums from Jamendo ( Which are only available using bittorrent or edonkey ), but since I have not yet found a way to do this, I decided to go the simple route for now and just launch the defualt app for handling torrents.

The result is, that it is now possible to select download from within the Jamendo service, and the torrent file will be downloaded and launched in your favorite bittorrent client. Not quite as smooth as the Mangtune downloading, but it works! For now, it is hardcoded to always select the ogg torrent, but I will add an option to select either mp3 or ogg.

And of course "pictures or it did not happen"



This week I will be working on the Magnatune.com site. We are currently working hard to roll out some exiting new features, that will also make a great impact on the Magntune service in Amarok. But more on that when it is ready!

I thought it was time to make a little noise again, so here is part whatever ( I think it is 3 actually ) of my "What have I been doing this week" updates.

The reason for the irregularity is quite simple that some weeks I end up doing mostly Magnatune stuff. And while this is cool in itself, and I am also working on some features that will have an impact on Amarok, it is not really something I can blog a whole lot about just yet.

Anyways, here goes.

This week I have been putting some more work into the new playlist. I added some new features ( more on that a little later ) but these turned out to really stress some of the sore points of the playlist with regards to performance. So a big part of this week has been spent making sure that the playlist holds up under load. For now, I have tested it with 3000+ tracks in groups of up to about 500 tracks. The 3000+ track part now runs really well, and as long as groups are not above about a 100 tracks each, these do not pose a problem either. For very large groups, performance does suffer a bit,but since the groups are meant to contain single albums, I am not really sure how much of an issue this is. In general, it already seems to run better with a large amounts of tracks added than the playlist in the 1.4 series. Also, remember that our focus is not, and have never been, on adding the entire collection to the playlist, but instead on using smart and dynamic playlists to provide the same functionality in a much more convenient way ( Dynamic playlist walkthrough ).

The new features I mentioned earlier is support for collapsible album groups. The implementation is basically done, but how it will be used ( whether automatic some how or purely manual ) is undecided, so for now, I made it a button that the user can press to expand or collapse an album, along with some very simple logic to make sure, that if we start playing a track from within a collapsed group, it is automatically expanded. I also brewed up some example graphics for how such a collapsed album could be visualized. Here is a screenshot:





Following the last few posts about the new playlist, we got a lot of very positive feedback in the form of mockups and ideas for how to improve the graphics. As I am no great artist, we really appreciate this and would welcome new ideas. However, if you wish to do mockups or try out some new ideas, please base it on this file as that will make actually trying it out in Amarok much simpler. It should be possible to figure out what each element is used for based on the group names in the file, but basically, an album group consists of a head item, a number of body items (one for each track - 2 ) and a tail item, with some alternate backgrounds rendered for every other item.


Over the last few weeks, I have also been keeping a little pet project. By showing this off now, I run the risk of being called a "sellout to the vocal minority" but such is life. Since the new playlist is based ( sort of ) on the model/view framework of Qt4, I wondered how difficult it would be to make an alternate playlist view that retains much of the look and feel of the 1.4.x series. Doing a small, but very limited, prototype of this turned out to be very simple, and it is now possible to alternate between the two views by pressing the little star button at the bottom right corner. Switching the view and ( just for fun ) minimizing the context view ( which is already possible just by resizing the 3 panes ), gives us something that looks like this:


That does look strangely familiar I think...

Now, heres the kicker ( and why I don't think I deserve the label of "sellout" ). I don't have time to bring this alternate playlist view to a usable state. And I am not even sure it is needed, seeing how the new playlist is really coming along very nicely. But the ground work has been put in place, so if anyone feels strongly enough about this feature making it into Amarok2 ( Some people has certainly been very vocal about not liking the new playlist ), now is the time to step up and implement it! Do note, that there is no guarantee that it will be possible to hide the context view in the future as this currently being discussed.

Last but not least, do remember our Roktoberfest We are 75% of the way, but the things are slowing down a lot, so we really need these last donations to reach our goal and keep the Amarok team hacking for another year!

My recent post about some of the features of the new playlist in Amarok2 seemed to really inspire people to come up with visual concepts that would make the playlist not only functional, but also look really sweet. One person in particular submitted a really cool mockup and was later kind enough to provide this as an svg file. After spending an evening turning this svg into a series of elements that could be used for rendering different elements in the playlist, as well as tuning the color scheme a little, as the grey color in the mockup looks really sweet on its own but clashed pretty hard with the blue shades currently used in Amarok, I present you with this:




In general we have not settled on a color scheme yet, so we might still go back to the grey, but for now this looks better in the overall scheme I think. Some of the elements of the mockup has not been implemented. most notably the collapsing of album art. The reason for this is that the current plan is to make the information displayed for items in the playlist customizable, which means that there will be a way t disable album headers completely. The text layout still needs a bit of work still as I think having the text in the album header in two lines might look better..

Also, I have spent some time making the playlist handle multiple groups in a more fluent way. This means, for instance, that it is now possible to "chop" a group in half by adding a foreign element to the middle of it. In the following screenshot, track 4 from the first album group has been dragged into the middle of the second group:



So far, I think this both looks good and promises great usability. But now the real work starts! Stuff like dragging an entire album around or removing an entire album from the playlist needs to be implemented. I am also still undecided about whether it should be possible to collapse the tracks in an album group to make it take up less space, which usually means that I am going to prototype it at some point to see how well it works. So there is lots of stuff still to do!

Yesterday was officially the last chance to upload jingles for our little Amarok2 startup jingle contest. We have received 15 very interesting a varied entries which the Amarok crew will be evaluating over the next weeks to pick a winner and 2 runners up. There is some really cool stuff among the contributions, and they can all be heard by going to http://ccmixter.org and typing "Amarok" into the search field.

Even if your entry is not among the top 3, it might be used for some of our future projects, such as the Libre/Creative Commons music internet radio station, "Radio Amarok" that our rokymotion team is working on.

A big thank you from the Amarok team goes out to everyone who contributed with their Jingles!

As some of you might have noticed, I skipped last weeks status update post. The reason for this was quite simply that I was doing a bit of Magnatune work as well as getting a new development workstation setup, so I did not really do anything interesting worth blogging about! This week I will be doing mostly Magnatune stuff as well, but I did spend the first two days doing a bit of interesting Amarok work that I thought I would share.


Since the new playlist for Amarok 2 is basically built using a QGraphicsView, we can do some realy interesting stuff with it. One of the things I have been thinking about was a way to group tracks from the same albums together to take up less space and avoid having the same cover shown over and over again. So after playling with this for a while, and completely discarding the fist prototype I did (as the other devs managed to convince me of the error of my ways), this is what I've come up with:



While the albums in this prototype looks like a coherent whole, each track is actually still an individual item that can be dragged around and removed just the same as with regular track items. Also, the header of each album is actually drawn as part of the first track in the album. This means that there are no "Ghost" elements and that the underlying playlist model can remain intact.

My favorite feature of the current implementation is that it groups items on the fly, meaning that if I insert a single track, it will appear as a normal track, but if I insert another track from the same album right after the first one, the playlist will rearrange itself to show the two tracks as part of an album.

There are many things that do not work really well yet, such as correctly updating groups when items are moved or deleted, but I will work on that. All in all, I think that this makes the playlist a whole lot more usable, while still potentially looking really good! I am still considering whether it should somehow be possible to collapse an album and show only the header ( and maybe the currently playing track if it is from within that album ) but this is something that can always be added later. Also, it might be interesting to show some more album related metadata in the group header that applies to the album but not the individual tracks, such as total running time.

And now for the part I really should not have to write... Please remember that this is a PROTOTYPE and as such no work has been done on making it look good yet. So pretty please, with sugar on top, don't complain about the layout or the horrible color used to mark items as part of a group, it is currently just trying to illustrate a concept.

As promised, here is once again a small update of what I have been spending the last week of Amarok hacking doing.


This week I have generally been diving a bit deeper into the Amarok and even kdelibs code to debug some pretty serious issues. The KIO system is in a bit better shape than it was at the beginning of the week, thanks to KDE dev. Thiago, and as I use this intensively for the services, Magnatune not least of which, this is really good news.

Other cool stuff that has happened over the week:

- SVG artwork. Our new artist Lee really came through for us this week with a load of new scalable vector graphics (SVG's) that has been integrated into Amarok. I worked on the main tool bar and the new service list backgrounds while Mark pulled some cool hacks with manipulating SVG's in real time to achieve a nice smooth animation of the new sidebar buttons. This new artwork can be seen in the screenshots below.

- SVG caching. It turns out that when you use as many SVG images as we do now, propper caching becomes very important. So I spent the better part of a day caching everything I could get my hands on, to great effect. Performance is much better in most cases now. We still do have some issues with the cache emptying itself every once in a while, causing lag as everything needs to be re-rendered, but this concern is shared with the plasma crew, so hopefully a solution is in the works.

- Playlist performance. Our new playlist had a nasty habit of recursively redrawing itself causing 100% constant cpu load as soon as any tracks were added to it. This was fixed.

- Service Framework / mp3tunes service. As the KIO issues had been keeping me from doing more real work on the dynamic fetching aspects of the service framework, I figured now would be a good time. The results of this is that the service framework is now much more usable for writing almost any kind of service imaginable. As a proof of concept I finished up the mp3tunes oboe locker service that I have had lying around for a while, and actually got it working perfectly in the space of just a few hours. Browsing and streaming from the locker inside Amarok is cooool!

- Playlist loader. One piece of code that had not yet been ported was the old playlist loader. This is needed in order to load any kind of playlist file as well as listen to many streaming radio stations. I have spent all day today ripping the old one apart and building a new, hopefully much simpler version. The new one currently only supports local and remote m3u and pls files, but at least it is working! This was also the last ingredient needed to make listening to shoutcast stations possible in Amarok2!

I guess these are the highlights. And now, onto the moment you have all been waiting for, screenies!!!









Over and out!