lfranchi

you may have noticed at the beginning of nikolaj's last blog post that he made a small reference to a competition that we are having to see who can come up with the biggest code-drop once trunk opens again. he then went on to describe his playing around with the navigation system in the left-hand browsers. well, i'm not about to let his challenge to unmet, am i? i can't let him take all the spotlight for himself!

so in order to make amarok more flexible, and give potential community members more tools at their disposals, i finally looked into adding scripting support to the Context View. just like plasma, you can write applets for the context view in a ridiculously small amount of code. the architecture (read: plasma) was always in place, but it was never really exposed properly and it was always a hack to get it to work. so of course, no one wrote any scripts. and so there are no amarok scripted applets at the moment.

but hopefully that will all change! because now i've given you all the power to write your own britney spears themed applets! and just in a few lines of code! i could sit around and explain, but i'd rather show you a picture:



and then because i'm such a great guy, i'll even show you the code that makes that magic happen:

plasmoid.drawAppletBackground = function()
{
return true;
}
plasmoid.dataUpdate = function(a, b)
{
if ( b.current )
label.text = "Playing " + b.current[ "xesam:title" ] + " from " + b.current[ "xesam:author" ] + " on " + b.current[ "xesam:album" ];
}
layout = new LinearLayout( plasmoid );
layout.setAlignment( 2 );
label1 = new Label( );
label1.text = "This is a javascript applet. Just to show off that we can get data from c++ dataengines, here's info on the currently playing track:";
layout.addItem( label1 );
label = new Label();
layout.addItem( label );

label.text = "This is a Javascript Applet";
plasmoid.dataEngine("amarok-current").connectSource( "current", plasmoid );

and, thats it. you'll be able to install new scripted applets directly from inside amarok, and have all the fun that you want. i'd like to note that this is still in a very early stage and all the UI bits are still a work in progress--that includes the currently location of the "Install New Widgets" button. i needed somewhere to put it, and that seemed good for testing.

so, nikolaj... whats next?

[if you're allergic to reading mildly rambling text, just skip to the nice screenshot at the bottom]

i don't know about y'all out there, but one of the killer features for me in amarok when i first started using it was the "append suggested songs" feature. i do love last.fm radios, but the idea of having amarok play me songs that i already have but just maybe never saw the connection between, all automagically, seemed like a brilliant concept.

however as anyone who had taken a peek at the 1.x code for dynamic mode knows, it was not the most elegant of features. it wasn't the most cleanly designed piece of code either. and so, things being as they are, it was tossed by the wayside when 2.0 came around for the new nifty Dynamic Playlists that we have.

i would wager that a sizable chunk of amarok 2 users have no idea what Dynamic Playlists are. what do they do? why do I have so many pretty sliders? what does it mean when I ask amarok for 100% ska and 100% britney spears and it spits out a playlist with neither ska nor britney? putting aside the fact that by denying me of britney spears it has already significantly degraded my quality of life, i've always found Dynamic Playlists hard to use because put simply, I don't have the metadata to make them useful. I don't have my tags labeled, nor do i have good genre tags, or even any good ratings (side-effect of amarok development, my database never lasts more than a few weeks). so i can't tell dynamic playlists what to play me.....


....but no longer! i've finally scratched the itch that i've had for months and months, and resurrected a similar artists feature like you had in 1.x. but as a testament to the new Dynamic Playlists, this is really two things:

1) Much more powerful than the suggested songs in 1.x
2) Just the beginning
3) The best vector for delivering britney spears music to your ears

I have a sneaking suspicion that one of the above is wrong, but can't quite pin down which. in any case, without further ado, this is what it looks like:



this new type of custom bias queries last.fm for artists similar to the currently playing track, and returns any that you have in your local collection. so you can play music you never knew you had!

but more than just creating a new bias, we now have a framework for any component to register its own new bias type. so a new service, say magnatune, could add a new bias that lets you also filter on magnatune tracks, or do a bunch of other nifty things that would otherwise not be possible. someone could easily write a new bias type that favors artists that will be playing shows nearby! this is all to say, expect great things. because even though you can't always get your britney spears, amarok is still here to comfort you.

So as Nikolaj has been blogging about his cool new features that he has in store for Amarok 2.1, I feel obligated to reply. Can't let him steal all the thunder and PR!

Amarok 2 introduced many new features, and undoubtedly one of the most controversial ones was the context view. All of a sudden this large area was smack dab in the middle of Amarok, sticking its nose where some users didn't think it belonged. Mostly, this was because it was not always as easy or efficient to display data the data that users wanted, or it was clunky and hard to use. As the context view evolved alongside libplasma, some of the constructs that were used became outdated as well. All in all, the CV was not, in my opinion, living up to its potential and was very much one of the weaker spots of Amarok 2.0.

What is to be done? Improve it, of course! Or, in this case, rethink the basic foundation of how the user interacts with the context view. There are two fundamental things that will be changing in the Context View that you will see in Amarok 2.1:

1) The Layout itself

No longer will there be an idea of "containments, or "activities" (in plasma-speak). This idea, while quite nifty, didn't really work out great in practice, making it hard to manage a large number of applets and move them around. The new CV has a toolbar, almost a bit like the task manager applet for your KDE desktop. This will allow the user to visually see all the applets that are in the contextview, and instantly switch to any applet that he/she wishes to see.

Basic screenshot:



Clicking on any of the applets in the toolbar instantly switches that applet to be the top-most applet. The applets after it are laid out directly underneath each consecutive applet. The little wrench icon that is visible switches between "edit mode" and normal mode. This is the edit mode:



Here the user can add new applets in any location, as well as remove applets. The user can also re-arrange the order of applets by dragging and dropping the toolbar representations.

2) The applets

The fragmentation of data among the different applets provides for a lot of flexibility but not a lot of visual coherence. I personally envision a few select "meta-applets", that take up the whole CV at a time, but integrate data from multiple sources and lay it out in a coherent, simple, and space-efficient manner. So, a "web info" meta-applet would have wiki information, last.fm artist bios, lyrics, upcoming events for the artist, and maybe more.

I do want to point out that these are very preliminary ideas that are still being fleshed out, and have not been fully reviewed nor accepted yet by the Amarok team. But with some luck Amarok 2.1 will have an awesomely solid CV that will be able to display much more information in a much saner form.

so the amarok 2 experience has been getting better and better in the last few weeks. one of the major issues that i've always had with using the amarok natively is simply that most kde apps look very out of place on os x. really, rather than out of place quite a few look *really bad*. this is not anyone's fault, oxygen by default just doesn't fit well with the os x interface, and all the subtle grey gradients and boderless elements just turn into a big white empty space. example:



The playlist browser on the left is especially horrendous, not only does it not fit into a reasonable amount of size and get truncated, but it also seems to contain arbitrary squiggles to delineate the different possible tabs, all swimming in a sea of monochromatic grey-ish. now, i had been trying change style for a while, but when someone helpfully pointed out i can set the style in kdeglobals (i don't have systemsettings or kcmshell4 on os x), i was finally able to play around. lo and behold, with the tweaked QtMac style (which illogic-al tells me is oxygen tweaked for os x), amarok already looks a lot prettier!:



it is hard to see in the screenshot above, but the overall color is darker, and feels less empty. there is much more definition around elements, and in general it seems like a half-decent UI. all i know is that i would no longer feel ashamed to show this to a non-techie friend of mine when the ask what i spend all my time doing.

now, amarok is still not a beautiful os x application. it is still mostly grey, with different shades used to distinguish and delineate elements. this was a conscious design decision in the amarok development process, and although we are in the midst of talking about tweaking the UI for future releases (2.0 is finalized), this is how amarok 2.0 is going to look. I think in the long term we need to look at how to tweak the different ports of amarok---for example, in my pipe dream i'm seeing amarok using qt/cocoa and getting native toolbars and sidebars---think itunes or mail or safari or last.fm player type header with the control buttons init. of course, currently qt/cocoa doesn't include qt3support hence it is a little more complicated for kde, but nevertheless, i think one day we'll get there.

meanwhile, we continue to quash mac os x amarok bugs, and you can now resize your window like normal! (who would have thought you need to manually add a QSizeGrip to get a size grip in amarok's main window?).

Ever since I switched to the dark side and bought a macbook pro this spring, I've had slight trouble developing (and using) Amarok 2 and KDE4. Imagine my frustration as I spent a week cycling through all possible permutations of {VirtualBox, Fusion, Parallels} and {Ubuntu, OpenSuse, Mandriva} trying to get a development environment that didn't make my eyes bleed (or my computer choke).

Anyway, after approximately 7 months, I have been able to finally use Amarok as it was meant to be used: native on OS X!

How did I do this, you ask?

The KDE Mac Site

However, if you want to be able to build a collection (as I have in the screenshot above), you'll need to compile/install mysql manually (following instructions for MySqlE). But just out of the box, I got perfect audio, low CPU/memory usage.. and in general awesomeness.

In other news, I have locally switched Amarok from using our old last.fm code to a brand new snapshot that will provide much more long-term stability. This should resolve the various last.fm bugs that have been around the Amarok code for quite a while. and you can see the result here:


Finally, if you are still wondering what other crazy stuff you can do with amarok, look no further:


let me give my huge thanks to our very own illogic-al, who has dedicated more brain cells to packaging amarok/kde on os x than i would like to count, and who is officially awesome.

so the very kind folks who won the Akademy awards last year ( sebastian trueg, matthias kretz, danny allen ) decided to go ahead and award Amarok with the Best Application award! we are obviously very excited and very pleased to win this award, and want to (tearfully) thank all those users who have been with us through the long dark (teatime of the soul) times of Amarok 1.x.... wait, we never had those. nevermind.

Anyway, I would like to thank everyone on the behalf of the Amarok team for supporting us, and most of all for believing in us throughout the long Amarok 2 process. It's coming. Soon. But Not Yet (tm).

The other winners of Akademy awards this year include Nuno Pinheiro (Oxygen) for Best Non-Application Contribution, and we're exceedingly glad to be able to say that we have been collaborating with Nuno to get some kick-ass new looks for Amarok. Our continued cooperation will definitely result in some pretty sweet new designs for Amarok, and we are really happy to be working with him.

The other winner of the Best Contributor to KDE is none other than Aaron Seigo, KDE dancer extraordinaire and resident party animal. After a late night saturday, Aaron was able to provide enough lap dances to the judges to sway their opinion in his favor, and he took home the goods.

I'm excited to be done with the talk portion of Akademy, and to get to the hackathon sessions. I'll have to find a way to get through the e.V. meeting tomorrow, but other than that, expect a productive week of amarok hacking coming up!

I'd like to welcome William Soares (Liw- on IRC), one of the Amarok SoC students for 2008. I'll let his words introduce him:

My name is William Viana Soares, I live in Spain although I am from
Brazil and this is my 4th year as a Computer Science Engineering
student. My goal during this summer will be to make Amarok Context
View more usable. I will focus on the the use of libplasma
capabilities to create a nice zooming user interface where all the
context information will lay. I will also be working on Amarok's
Plasma packaging system and in the development of new applets with
contextual information.

I'm really excited that my application was accepted and I'm looking
forward to start coding and see my improvements done for the sake of
Amarok and my own since I'm an Amarok user

We are very glad to have someone working on the Context View again this summer, and i personally can't wait to see all the exciting things that he comes up with.

so as FOSSCamp was in boston this weekend, i couldn't help but make my way down the The Hotel @ MIT and meet (for the first time) other KDE developers! in particular, i finally met jeff---even though we now live in the same city, we had not yet met face to face yet. all in all, FOSSCamp went quite well, most of it was spent hacking with Jeff in order to get a workable demo of Amarok2, but i managed to attend a few sessions nevertheless.

One thing that surprised me was the sheer difference in numbers between KDE and Ubuntu people there me, jeff, troy, and robert (plus riddell and kwwii kinda held down the fort against the full brunt of the ubuntu developers... we managed to get a few KDE sessions in, starting with the KDE4 core technologies session on saturday afternoon. without repeating too much of what has already been said, i t hink it went really well, and people were especially impressed with all of our new "integration" technologies like Solid, Phonon, etc. the whole abstraction-and-ease-of-development thing went down quite well with everyone attending.

the KDE4 apps session that we did on sunday afternoon was basically a demo of plasma, a few kde apps, and amarok. unfortunately we got a much smaller turnout, but it was amongst the last presentations at the conference. nevertheless, after robert went through the desktop and some basic apps like dolphin and marble, jeff took the stage to demo the awesomeness of the new amarok2. we managed to provide a nice example of how all the KDE4 technologies actually make a difference: the Phonon engine is only ~300 LoC compared to ~2100 for the Xine engine. pretty amazing.

anyway, i'm glad i had the chance to meet and chill with KDE developers for the first time.... it felt weird talking about kde and amarok and coding and things that that in real life!

so my last entry got quite a number of comments, mostly negative, some based on incorrect assumptions or understandings, etc. I want to take the time to explain the design decisions and lay down the facts.

first of all, the major complaint seems to be that the contextview takes up too much room, and makes the playlist too small. the size of the contextview/playlist is configurable. yes, you can drag the barrier to decide how large you want it. guess what, you can even make it take up the complete contextview space, hiding the plasma panel! there will be no barrier to you using the whole window for playlist management if you wish. of course, then you will miss out on any info displayed in the contextview, but that is your choice.

the next big complaint that i have seen is that the playlist items are too "big", not allowing for a lot of items on the screen at once, making it hard to manage them. as we are using the Qt model/view architecture for out playlist items, it will not be too hard to implement an amarok-1.x style playlist as an option for simply managing your music. that is under discussion, and might be the final solution. either way, we envision a way to use amarok that will make it easier to manage music than the narrow playlist.

for those who, understandable, point out that the large contextview makes dragging from the collectionbrowser to the playlist very very hard, we understand you. we are not going to force users to drag anything all across the contextview. our plan is currently to implement a sort of popup drop-box over the contextview when a drag is initiated, with icons or some sort of visual indication for where to drop the selected tracks in order to achieve certain actions. that way the user will not have to drag-n-drop any tracks more than is reasonable.

for those who say they just want amarok to play a large (1000+ tracks) playlist of music, and that they don't care about all the bells-n-whistles like context info, etc, well, i don't know what to say except you might be better off with xmms. if all you want is to hear your music, amarok is probably not the player for you---and has never been. we want to bring the user more context information, in a prettier way, while not hampering his ability to play/manage music. not the other way around.

a few are worried about the potentially wasted space in the contextview as applets can be positioned, and sized, differently. well, applets are not going to be user-placeable except for in a very limited manner. this is where we differ from plasma---the user will not resize applets to her liking, putting them where she wants. instead, amarok will take care of the layout management of the contextview, ensuring that the full width of the view is used, resizing and placing applets where needed to maximise the screen real estate. we will not waste any screen real estate

to conclude, please keep in mind that this is a very early screenshot. the work on the contextview is nowhere near finished, polished, or perfected. the playlist is still in the middle of being redone, and improves every week. we do have usability people who are working with us, and we are not just trying to innovate for the sake of innovation. we are all amarok users before amarok developers, and we want the best possible music player as well.

hello planet to those who don't know who i am, my name is leo franchi, and i'm working on amarok for my SoC project this summer.

we've decided that for amarok 2.0 we want to emphasize what used to be called the "context browser" in amarok 1.x speak. we decided to break out the context browser into its own central widget... and have re-used libplasma to implement it. this allows us to use all the goodness from plasma with minimal effort (there is of course some tweaking required). as we do not depend on kdebase, we are currently svn:externing libplasma in our amarok tree and linking to it internally. I understand that post-4.0 (4.1 maybe?) libplasma will be broken out into its own separate library, and we will be able to depend on that.


using plasma we get to use gorgeous svg-themed applets, the clean and flexible applet/data engine architecture, plus many smaller but no less important features.

so if you're curious about what amarok 2.0 will look like, look no further:

hey everyone, my name is leo franchi. quick intro: i'm 19 (as of today!), to go Tufts University, and am working on Amarok for my SoC 2007 project.

my project involves web service integration to Amarok 2.0: that means new contextual info from the web, think concerts, last.fm friend stuff, etc. as most of you know, amarok 2.0 will feature a new context browser, now called the contextview and based on QGraphicsView. as we leave KHTML as our technology of choice, we are left with a dilemma: customization. with KHTML it was very easy for the end-user (or modder) to customize the contextbrowser. using CSS, everything could be controlled.

but KHTML was one of the main reasons we left the old CB for the new QGV, and so the question of styling returns. the text inside the items on the context view is potentially styleable (but with much messyness) but the style of the physical QGraphicsItem (QGraphicsRectItem) not so much in this case. so i ask you, the users, for input: how much customization do you need? comments are appreciated as we decide how to implement what could be one of the centrally visible parts of the new amarok 2.0 interface.

leo