Wednesday, February 20. 2008
A few days worth of work
For the last few days I have been hacking on Amarok full time, and I though it was time to give a brief update on what is happening on planet Amarok.
Lets start off with the screenshot this time
First of all, we have now officially made our svn trunk depend on Qt 4.4 and KDE 4.1 ( current KDE trunk ). This means the that the work that was done with QWebKit ( See my last blog entry ) has been merged into trunk and we have started using QWebKit and real widgets in some of the other applets. Because of this, the Wikipedia and Lyrics applets are also coming along nicely, but they are not really fit to be shown off just yet.
In the above screenshot, there are 4 major visible changes. First of all, the the 2 different statusbars that we were using ( one below the context view and one below the playlist ) has been merged into one that is placed at the bottom of the app. Besides looking much better, this also means that you won't loose a statusbar if you decide to hide the context view. The statusbar code has also been cleaned up somewhat, even though this is still very much a work in progress.
Next up is "source info capability" that can now accompany a track. I thought it was a bit of a shame that it was not possible to tell which tracks in the playlist are local, which ones are from Magnatune.com, last.fm, Jamendo or wherever. So to solve this I added a system for letting each track tell the world a little about where it is from. The first use of this system is to display a small emblem in the top corner of the album covers for tracks from the services. In the screenshot can be seen the emblem for Magnatune.com service tracks. I plan to make displaying these emblems configurable so people who do not like it can turn it off. I am also not sure that the emblem really needs to be shown on top of the cover, but I have no been able to come up with anything better yet...
Then, smack in the middle, is the resurrection of some very old code from before we started using plasma in the context view. Back then, I had this idea that some info was suitable for being presented in a "cloud" format. I had a context box that could display the different moods that Magnatune tracks are tagged with, with the relative size of each mood depending on the number of tracks that are tagged with it. After digging up some old code, it proved relative simple to get this ported and working in a plasma applet. The different shades of blue is thanks to the fade animation that happens when you mouse over an item. Originally, clicking on a mood would add 10 random tacks with that mood to the playlist, but I have not quite gotten to that part in the current implementation yet. There are also many other things that needs to be improved , such as text size adjustments, eliding, and, in particular, scrolling!
Last but not least I have cleaned up the playlist somewhat and changed some of the graphics a bit. The "now playing" marker is now much more visible on very light color themes ( remember, the svgs adapt to the users color settings ) and some redrawing issues have been solved.
Besides the visible, I have also had time for some code cleanup, crash fixes, and a little hack that, at least for now, makes it possible to use the shoutcast service again. I will be at Fosdem this weekend with the rest of the team, so hopefully I will have a little more cool stuff to show off by then!
All in all I don't think that is too bad for 3 days of work
Oh, one more thing! As you can tell, we really need some good artists to come up with a consistent theme for our plasma applet.! So if this is you, please get in touch!
Lets start off with the screenshot this time
First of all, we have now officially made our svn trunk depend on Qt 4.4 and KDE 4.1 ( current KDE trunk ). This means the that the work that was done with QWebKit ( See my last blog entry ) has been merged into trunk and we have started using QWebKit and real widgets in some of the other applets. Because of this, the Wikipedia and Lyrics applets are also coming along nicely, but they are not really fit to be shown off just yet.
In the above screenshot, there are 4 major visible changes. First of all, the the 2 different statusbars that we were using ( one below the context view and one below the playlist ) has been merged into one that is placed at the bottom of the app. Besides looking much better, this also means that you won't loose a statusbar if you decide to hide the context view. The statusbar code has also been cleaned up somewhat, even though this is still very much a work in progress.
Next up is "source info capability" that can now accompany a track. I thought it was a bit of a shame that it was not possible to tell which tracks in the playlist are local, which ones are from Magnatune.com, last.fm, Jamendo or wherever. So to solve this I added a system for letting each track tell the world a little about where it is from. The first use of this system is to display a small emblem in the top corner of the album covers for tracks from the services. In the screenshot can be seen the emblem for Magnatune.com service tracks. I plan to make displaying these emblems configurable so people who do not like it can turn it off. I am also not sure that the emblem really needs to be shown on top of the cover, but I have no been able to come up with anything better yet...
Then, smack in the middle, is the resurrection of some very old code from before we started using plasma in the context view. Back then, I had this idea that some info was suitable for being presented in a "cloud" format. I had a context box that could display the different moods that Magnatune tracks are tagged with, with the relative size of each mood depending on the number of tracks that are tagged with it. After digging up some old code, it proved relative simple to get this ported and working in a plasma applet. The different shades of blue is thanks to the fade animation that happens when you mouse over an item. Originally, clicking on a mood would add 10 random tacks with that mood to the playlist, but I have not quite gotten to that part in the current implementation yet. There are also many other things that needs to be improved , such as text size adjustments, eliding, and, in particular, scrolling!
Last but not least I have cleaned up the playlist somewhat and changed some of the graphics a bit. The "now playing" marker is now much more visible on very light color themes ( remember, the svgs adapt to the users color settings ) and some redrawing issues have been solved.
Besides the visible, I have also had time for some code cleanup, crash fixes, and a little hack that, at least for now, makes it possible to use the shoutcast service again. I will be at Fosdem this weekend with the rest of the team, so hopefully I will have a little more cool stuff to show off by then!
All in all I don't think that is too bad for 3 days of work
Oh, one more thing!
As you can tell, we really need some good artists to come up with a consistent theme for our plasma applet.! So if this is you, please get in touch!Trackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
Seeing this tag cloud:
Will it be possible to synchronize the Amarok labels with the last.fm tags (I mean uploading them to my personal last.fm account)?
This would probably be a nice feature...
Will it be possible to synchronize the Amarok labels with the last.fm tags (I mean uploading them to my personal last.fm account)?
This would probably be a nice feature...
There's no reason why we can't do tagging to last.fm. We have the code there to do it already, just haven't implemented anything. It's something I'll get around to eventually (unfortunately not spending a lot of time right now on Amarok development).
Is that song progress bar going to be customizable? I don't know if I'd enjoy having the song progress all the way across a screen with very high resolution. Is there a way to have the progress just be as long as the volume bar or a bit longer? That would seem to be decent. Less mouse movement.
It's not customizable (and won't be), but we'll give it some more thought and usability testing before the release.
In general we think that a longer seek slider allows for improved precision, which is good. Just how long it needs to be will be subject to experimenting.
In general we think that a longer seek slider allows for improved precision, which is good. Just how long it needs to be will be subject to experimenting.
1) assume you have a song 10 minutes long (a really long one), that's 600 secs. even if you want to be able to accurately seek to every second you only need it to be 600 pixels long.
2) while it's good to have as much seeking accuracy as possible when it comes for free, seeking is not a fundamental part of the "listening to music" experience and the current area with the controls and the seek bar is wasting a lot of space. space that could, for example, be used by the plasma area, which seems more in line with the "discover your music" motto.
3) a really long seek bar only gives the illusion of seeking accuracy because it's actually limited by the song length and the playing engine.
have you guys considered putting the controls, the seek slider and the volume control at the same level? something like:
img99.imageshack.us/my.php?image=mockupqj1.png
(http protocol missing because of anti spam prevention...)
2) while it's good to have as much seeking accuracy as possible when it comes for free, seeking is not a fundamental part of the "listening to music" experience and the current area with the controls and the seek bar is wasting a lot of space. space that could, for example, be used by the plasma area, which seems more in line with the "discover your music" motto.
3) a really long seek bar only gives the illusion of seeking accuracy because it's actually limited by the song length and the playing engine.
have you guys considered putting the controls, the seek slider and the volume control at the same level? something like:
img99.imageshack.us/my.php?image=mockupqj1.png
(http protocol missing because of anti spam prevention...)
It's one of those "can't please everyone" things. Some people complain the plasma area is too big. You want to make it bigger. You think to the second accuracy on a 10 minute song is all anyone needs ... other people want to be able to type the exact time into a box for audio books that are hours long.
yes, i understand that you can't please everybody. but that doesn't means this decision (as others like this) shouldn't be made by weighing the pros and cons of the possible choices, and i don't see any pros in the current layout (a slider 33% longer wouldn't help at all with a 2 hour book, for example). if there is a case supporting it, then fine by me, but i haven't seen it. i don't know... maybe you guys think the current layout looks better? (while i would disagree with the judgment, that would be a valid reason).
I like the symmetry of the current layout, but that's just my opinion. I'm not responsible in any way for it.
Usability wise I'm not expert, but in general bigger = better from what I understand. Apparently the average user can't hit the broad side of the barn with a mouse.
Usability wise I'm not expert, but in general bigger = better from what I understand. Apparently the average user can't hit the broad side of the barn with a mouse.
I like how that progress bar is get bigger because usability and i like symmetry on playing controls. But for what im consider, is that plasma area size (is it possible to hide it to have just two bars, collection + playlist?) for smaller screen or those who dont like to have music player in fullscreen but still have collection in view. And then that playlist area, on every screenshot it has full albums. And i dont personally listen full albums or even few songs from one album, so i have playlist full of different artist songs.
I might update my system to KDE4 to see that how it works and fill some wish/bug reports. Because i dont like to see space wasted when 30-50 different artist is in playlist. If i need to scroll long way to play/see other songs, its bad usability someway. Currently Amarok just use nicely that space because playlist can take so big area, but Amarok2 does look much better with whole albums and it's nice.
I might update my system to KDE4 to see that how it works and fill some wish/bug reports. Because i dont like to see space wasted when 30-50 different artist is in playlist. If i need to scroll long way to play/see other songs, its bad usability someway. Currently Amarok just use nicely that space because playlist can take so big area, but Amarok2 does look much better with whole albums and it's nice.
I sure know that I'd enjoy having the seek-bar as wide as possible. I currently often maximize amarok horizontally (rmb on maximize for higher seek resolution.
for higher seek resolution.
Amarok Links
Calendar
Quicksearch
Categories
Syndicate This Blog
Blog Administration
We Listen To...
Powered by
