Wednesday, December 31. 2008Project Neon: KDE Nightly Edu++ GGadgets++
If I had more time for blogging I would do more blogging... but I don't have
 Quick update: Newly available in Project Neon's kde-nightly is kdeedu (i.e. kde-nightly-kdeedu). Newly available in the kdebase build is support for Google Gadgets (using GGL SVN from yesterday). Upcoming is Quassel (which got KDE integration) as well as the return of MSN in Kopete. 
Wednesday, December 31. 2008Project Neon: KDE Nightly Edu++ GGadgets++
If I had more time for blogging I would do more blogging... but I don't have
Quick update: Newly available in Project Neon's kde-nightly is kdeedu (i.e. kde-nightly-kdeedu). Newly available in the kdebase build is support for Google Gadgets (using GGL SVN from yesterday). Upcoming is Quassel (which got KDE integration) as well as the return of MSN in Kopete. Monday, December 29. 2008Context View, Reborn pt. 1
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. 
Sunday, December 28. 2008From the Post 2.0.0 Git Vaults, Part 2, "The Playlist - Evolved"
Back in part 1 I showed a few of the things that will make it into Amarok 2 at some point ( likely for 2.1.0 ).
Today I want to show you another thing that I only recently started working on. Its another somewhat controversial part of Amarok 2, namely the playlist. Since we first started showing screenshots of where Amarok 2 development was heading, some people have been unhappy with our idea of a new and improved playlist ( and have been extremely vocal about their displeasure ). We have tried reassuring them that the playlist would, in time, come to encompass many of the things from Amarok 2 that they were missing as well as a whole lot more, but it is always hard to communicate such ideas with no screenshots to back them up. So, since I just today got something running that finally demonstrates some of these ideas, I rush to blog it!  Please note that this code is still at a very early state and that there are a few rendering inconsistencies visible that will get sorted out before this ever makes it into trunk.What this new code does, is basically make the way each item in the playlist is rendered completely configurable. how any rows there should be, what elements ( title, album, artist, score, ... ) should be shown in each row, how much space each element should be given and so on is all fully configurable. (Configurable from a code point of view, the ui for actually configuring it does not exist yet... ). So for instance, configured to mimic the current playlist layout, it might look like this:  That looks a lot like the current playlist, only slightly uglier because of some of the rendering issues I mentioned earlier. Messing a bit with the ( for now, hard coded ) config for the playlist and adding a few elements to some playlist item types we can create something like this:  Here we have added the score to all body item ( tracks in an album group ) and given the title its own line for single track items. Finally, as the grand finale, for people who prefer the Amarok 1 playlist, it is possible to do something like this by making all items have just one line ( and the album header none, thus making it invisible ) and use the same config for body and single track items:  For dramatic effect I have also hidden the context view!  Add to this some decent sorting controls, and basically all the functionality from the 1.4.x playlist can be brought back. And yes, some of the items are "jumping a bit", this is one of the rendering issues I mentioned. I think this playlist will end up being much more configurable and powefull than the 1.4.x one ever was, even if this was not immediately visible in the Amarok 2.0.0 release. But as we have said many times, Amarok 2.0.0 was just the beginning. Now comes the hard part, creating a sane ui for letting the user configure the playlist layout. Luckily, Dan has the concept of how this will work well under control. Sunday, December 21. 2008Happy holidays from your Amarok Team! Yes, this is actually edible! My partner Myriam made these special cookies for me, as a gift for our successful Amarok 2.0 release. Rest assured, I will enjoy the cookies very much. I know they taste delicious I'd like to wish all of our users, our Amarok squad, and the KDE team a happy holiday season! Saturday, December 20. 2008Weekly Update: Unhidden Biases
Now that dynamic playlists are working, what's missing is a way to actually use them. That's what most of this weeks work went towards.
In Amarok 1, dynamic playlists are one of those great hidden features. They are terrifically powerful and usefull, but a lot casual users don't know about them, or just don't understand how to use them. I had been using Amarok for a while before I discovered them. One of the problems I've been working on is how to present Amarok 2.0 dynamic playlists in a way in which it's more or less obvious what they do. I want it to be an exhibitionist feature, with the functionality all exposed and out in the open, no dialog boxes or menu hierarchies. This week I spent some quality time working on the bias editor (and reminding myself why I don't like gui programming). Since every blog post needs a picture, here's the latest version of the bias editor from just a few minutes ago (not even in svn yet). It's a bit rough arround the edges, but comming along nicely.  That screenshot is slightly faked, but in the next few days the bias editor will start to become functional. I'm pretty excited to see my work actually usable. I also did some important work behind the scenes. This sort of playlist generation can't really be done efficiently in general (it's an NP-hard problem). If you give it a really tough set of biases, it won't break down or freeze up, but it may give you playlist that isn't perfect. Making the solver work well is a matter of heuristics, trial and error, and tweaking. I did a little of that this week, but the real testing and tweaking will happen when the bias editor is up and running. I'll be back here in a week, hopefully demonstrating how to use the new dynamic playlists. Saturday, December 20. 2008Weekly Update, Secret Plans Divulged, &c
I've been struggling with how to describe what I've been working on succinctly in conversation. I figure I can get about two sentences in before I start getting blank stares and eye rolls. I've been using something like this:
You know how when you put your ipod on shuffle, it magically knows what you want to listen to next? It's a little like that, but completely customizable, and instead of magic it uses a stochastic optimization algorithm. Then they say something like "Hmm", or "Interesting," and then there's a long uncomfortable silence until someone changes the subject. "Can you believe this weather we're having?" This is Week 2 or so for me, and forgoing things like "sleep" and "food", I've made some significant progress. The core of the bias code is written and more or less works. Random mode in working just dandy and if you're running the nightly or svn of Amarok 2, you can find it under the Playlists tab hiding out at the bottom. Since the bias code is written and works, this is a good time to talk about my secret plan. When a I first proposed biased playlists, I described biases as the chance that track has a certain property. Like "30% chance the next track is Jazz". I even made an aesthetically appalling mockup to show what I meant:  The secret is, that I've designed it to be much more general than that. A bias is any function that maps a playlist to a value in [0,1]. The solver will then try to find a playlist where all the biases are at 0. Blank stares, eye rolls. "Can you believe this weather we're having?" The point is: biases can do a lot more that what I described previously. Really, they can impose any kind of restriction on the random playlist being generated. For instance, Suggestion Mode, where the next track is from a similar artist as the previous, can be implemented as a bias. If Suggestion Mode is just a bias, it can be combined with other biases. We could do Suggestion Mode + 30% Metal + 70% pre-1990, and it will do its best to find a playlist that matches fits. It there is no such playlist, it will just give you the best it can come up with. This also really important because it lets us use fuzzy biases like: "arround 1976", "about 3 minutes", or "hasn't been played in a while". Presumably, users could script their own biases, doing wacky things so playlists are random but tracks have increasing lengths, follow an obscure integer sequence, or their titles spell out a secret message. The next few weeks i will mostly be concentrated on tweaking and optimizing the solver and working on an easy way to create biased playlists. There's a lot of work ahead, but I'm very excited with how it's gone so far. Thursday, December 18. 2008Amarok 2 playlist searching
First of all, just to get the terminology straight. In this post, I define a filter as something that limits what you actually see in a view, and a search as something that selects items in the view without affecting other elements.
Amarok 1 style playlist filtering. Since Amarok 2.0.0 was released, one of the frequently mentioned Most Missed Features (MMF) is the Amarok 1.4.x style playlist filtering. The filtering in Amarok 1.4.x is indeed very powerful, but it also suffers from a number of usability problems and is actually sort of a weirdly placed feature as the collection is where advanced filtering is meant to take place as it will always haver more powerful mechanisms for advanced filtering. That said, we are very aware that there needs to be a simple way of locating content in large playlists and perhaps even limit the playback of tracks to a subset of what is in the playlist in a non destructive way. Inspired by the progressive searching in apps like Firefox (and indeed many of the KDE 4 applications) we decided to try this out instead. So, hidden away in a small cabin in the very dark woods, far away from streetlights and traffic, I decided to have a go at this. Amarok 2 style playlist searching.  This morning I committed the initial version of a rather advanced playlist search feature. At its very core, it is just a progressive, as you type, search. This means that as you type, the first track that match the current search term will be selected (and the playlist scrolls to it). Next and previous buttons then allows you to jump around in the tracks matching the search (These really need to get some keyboard shortcuts... Working on that one). The search edit gives immediate feedback on whether there are any matches or not, in the same way that, for instance, the KDE 4 version of Konsole does. By turning the search edit a different color and disabling the next and previous buttons. Now by itself, this is useful, but not super powerful, but this playlist search has a few additional tricks up its sleeve. It is possible to specify which fields should be matched against when typing a query. This is changed by clicking off the fields in a small drop down menu. Currently it is possible to search any combination of track name, album name, artist name, genre name, composer name or year, and I have a few more ideas for properties to search that i am going to add.  It is also possible to "lock" the track progression to only play tracks that matches the current search term. This is toggled using the same small drop down menu. It provides a very convenient way of just playing a particular artist from your all time favorites playlist or any number of similar use cases.  Currently this only works when using "standard" or "random track" playback modes however, and I am still pondering whether it actually makes sense for any of the other progressions modes, such as "random album". All the options from this drop down menu are of course stored in the config so the options are persistent across sessions. We are aware that some people will still miss the old style filtering and that this is not the same thing. We do believe however that a search makes more sense in the playlist than a filter, and that this satisfies many, although not all, of the use cases that the old filter did. Going forward, it might also be possible to add other features to the search, such as selecting all matching tracks, or exporting matches to a new playlist, if there are use cases that support these additions. One thing I am still pondering is if the filter bar should be visible at all times, making the feature very easily discoverable, or if it should only appear when the search keyboard shortcut is activated.... As mentioned, I committed this code this morning, and baring any major issues turning up, it will be appearing in Amarok 2.0.1 which should be released shortly after new year if all goes well. If you cannot wait that long, it should be appearing in the nightly builds shortly, and failing that, there is always building straight from svn! Friday, December 12. 2008Amarok 2 rocks the house: A review roundup After our recent release of Amarok 2.0, the first round of reviews from major Internet sites has hit the tubes. It is interesting to note that while we got slightly mixed reviews from our users, the majority of professional reviewers had mostly positive things to say about our baby. I'm not surprised at all by this outcome - I've been long enough in the software business to know the rules. Again I would like to emphasize that we take every criticism very seriously, as long as it is constructive. And we have a very firm vision of Amarok. Everyone who has met me either on the Net or in person knows that I'm a man of strong visions in which I firmly believe, and that I'm not easily influenced by others to change my views. Enough of the banter! Let's get to the meat: Ryan Paul of Ars Technica posted an extremely well written and in-depth review: Hands-on: Amarok 2 rocks the house Jeremy LaCroix wrote a balanced and fair review for Linux.com: Amarok gets a facelift Kevin Purdy of Lifehacker has written a short but sweet review: Amarok 2 Released, Windows and Mac Versions in Beta Austin Modine of The Register reviewed Amarok 2: Native-Linux music player Amarok gets major overhaul That's all for now. If you discover any more noteworthy reviews, please post them in the comments section. I might eventually write a follow-up to this article, or simply caress my (planet sized) ego by enjoying the reviews. Mark Kretschmann Thursday, December 11. 2008Wednesday, December 10. 2008MTP File Management and iPod Covers
So MTP file management (copying/deleting) has gotten implemented, and works well on all 3 devices I tested on. Still a lot of polishing left to do as far as interface goes, and some threading to not stall Amarok at key points, and it should be good to go. One thing I'm having issues with is copying files directly from an MTP to an iPod and vice versa, but will investigate this later as this is a bit more advanced.
So, I had a bit of an epic struggle with a few things over the last day or so. See, libgpod can only retrieve covers in the form of GdkPixbuf structs, but so as to not force the GdkPixbuf dependency on people, they return it as a gpointer which you can then choose to cast if you want to use GdkPixbuf. Sounds great, right? No problem... ... except for having CMake pull in the dependency. So as it turns out, there's no built-in module for gdk-pixbuf library. So, I decided to create my own as I did with libgpod, except when I pulled it in, a certain function wasn't present. Odd... hm. Well as it turns out, this function is only present in the gdk-pixbuf library that resides in gtk. Great! There's a CMake module for GTK, all should be fine this time, yes? No. The GTK module in CMake pulls in GTK1, and gdk-pixbuf is in GTK2. So I end up modifying the gdk-pixbuf module I made before, learning lots about CMake along the way, and finally get it compiling. Long story short for the next part, the README in libgpod didn't really work for me for setting up SysInfo for my iPod, and I accidentally tripped on a feature from the old Amarok which set it up right, after I modified some permissions. Wonderful, yeah? Wrong! Turns out that iTunes and libgpod handle covers in two different ways, and so I have to cater to both of them. This turned out to be a bit of a pain, but at last, I finally got a size-distorted but correct solution:  The m-flo cover was set by me using libgpod via Amarok, and the Maná cover was set by iTunes. I'm going to fine-tune the sizes later, and all should be peaches and cream. That's all for now. One note though about the interface, which right now is either non-existent or bad: likely going to be making an applet which does all the fun stuff that A1 did for media devices, including: connect/disconnect, % free space, possibly a queue, and if supported, even % battery level! That however, is a ways away from coming true, but do stay tuned. Wednesday, December 10. 2008MTP Support Arrives Caption: 2 MTP devices connected, and songs playing from iPod This is a bit overdue, but initial support for MTP devices has arrived. To use it, you require limbtp >= 0.3.0 installed on the system, and a device supported by libmtp of course. Part of the reason this took so long is that I'm starting to notice a lot of potentially reusable code, and will probably soon refactor to reflect this. MTP devices are strange beasts, because their filesystem can't be directly accessed. As a result, Amarok 1 and Windows Media Player et al can only do file management of tracks on these devices, not actually play directly off of them. I'm going to be working on an idea that allows playing off of them to be possible, because let's face it, A2 is an audio player, not just a file manager. Thanks again to everyone who donated MTP devices to the Amarok group. You're the ones who make this possible. Support is still pretty basic, so please don't file bugs on this yet, but be ready to at some point in the semi-near future. Edit: Snapshot of 3 Mentioned Devices 
Wednesday, December 10. 2008MTP Incoming and Ipod File Deletion Support
First off, thanks to everyone who has responded to the request for devices so far, and those to come! Sorry if the replies to the e-mails take a bit, but I'm probably working on Amarok ironically enough. Some of the devices offered have already been sent, and soon we'll see the first signs of MTP support on Amarok 2 =D . To get this question out of the way, yes, of course we're going with libmtp 0.3, it just makes sense to. Look forward to this MTP users, and thanks again to all donors of devices!
Summary of Ipod News: - You can now delete files one at a time from the iPod - You can now "edit" tags, although changes won't save yet (implementing next)  After fighting for a while with how to create a custom "remove" button, users now have access to deleting files on the ipod! ... one at a time, hah, looks like I have to do some more magic before you can do it with multiple files at once. Also, the icon for "remove" doesn't seem to make sense, and I'm fixing this soon too. Why there isn't a built-in capability to remove from a collection when there's built-in support for it in CollectionLocation? Probably nobody got around to it yet. If nobody does it after this summer, I'll implement it so that people don't have to go through this again, haha. Turns out that because pre-made actions are in the CollectionTreeView, they can do all sorts of magic like... know which items are selected, so that they can work with multiple things at once. I'll have to look into this next. Anyway, editing ipod tags will no longer crash your Amarok, and they'll even update in the view!... but not in the ipod's database, so a restart of Amarok will clear those changes, don't be fooled! It won't be too hard to port over tags support I'm sure. Er.. wait, I've said "it shouldn't be too hard to..." way too many times already, and I'm always surprised when it turns out to be a pita, haha. The rest of the stuff I mentioned in previous posts has not yet been dealt with. No need to ask about the progress, it'll get here fairly soon. I've tried to concentrate on core features (tag editing, file management) for now. Yes, album covers and podcasts are wonderful, and they're soon to be here. Wednesday, December 10. 2008Ipod Collections Visible
As predicted would be done by today, Ipod collections are now visible in Amarok 2 if an iPod is plugged in at Amarok 2 loadtime. I'll add signal/slot stuff so that you can plug in later at a later time. Songs are playable, but track information edit attempts crash amarok, and it's hanging on exit probably due to some voodoo static_cast that I'm using. Instead of the 30-90 seconds of Amarok 1.4 freezing loading my ipod, this takes less than 1 second and freezes nothing. Anyway, screenshots:
  As you can see, UTF8 support is there, although there's some funky business with Album grouping atm but I'll get to that. There's a long series of known bugs right now, so please don't bother me just yet with them as they're mostly obvious ones =p This is a big milestone for me, as I can start to see that what I'm doing is quite possible. Still a long road ahead, but we're on our way. Wednesday, December 10. 2008KDE4 on Gentoo After weeks of trying to get to setting up a KDE4 development environment for Amarok, success is finally at my door =D. First Kubuntu and kdesvn-build needing every dependency imaginable and building issues, then Gentoo and the broken qt-4.4 ebuilds, but a combination of kdesvn-build and manually building Amarok has finally granted me my dream. For a higher quality version, download from here(note: .ogv file) : http://www.filesend.net/download.php?f=03f4722730dfa9115d143701fd0d3db1 For an avi version (lesser quality a bit) : http://www.filesend.net/download.php?f=bdbe2dcd1626b6aa2f3ab5d78888bcae |
Amarok LinksCalendarQuicksearchCategoriesSyndicate This BlogBlog AdministrationWe Listen To... Powered by
|
