Like quite a few KDE community members who attended Akademy 2008, I got a Nokia N810 internet tablet. Sadly, shortly after we got the devices we stopped receiving OS updates and the Maemo Diablo platform was basically abandoned in favor of a bigger better faster and quite different Maemo Fremantle, to be used on the N900 with the hope of eventually having a community supported port for the N810. Unfortunately, the Mer project, which aimed to bring as much Fremantle as possible to the N810, was cancelled back in 2009, leaving N810 owners with a nice piece of hardware and a dead software stack.
Don’t get me wrong: while the browser is still slow as molasses and the battery drains quite quickly when WiFi is on, Maemo Diablo works, but it’s not moving and in 2011 it’s not fun any more. Lately I’ve been using it just as a music player and rarely for quick note taking or Skype over WiFi.
So thanks to the efforts of the Nitdroid project, I installed an Android 1.6 Donut build on my N810, hoping to get something fun to tinker with. Even though Donut is old, it might still have been an improvement over Maemo Diablo. From what I’ve picked up, the Nitdroid project is focusing on the N900, and I can testify that Android on the N810 is unusably slow.
I have managed to open Planet KDE on my third attempt, the first two times stuff just crashed randomly:
As for MeeGo, a fellow Amarok developer says it’s slow even on the N900, so does it even make sense to try running it on the N810?
What are my options if I want a fun, fairly recent and at least a bit usable system on my N810?
I know people even managed to run KDE on it, but is it fast enough to be usable?
What do you use your N810 tablets for in 2011?
Unsurprisingly, this fall has been a busy time for the Amarok squad: we had several heaps of code to merge from this year’s Google Summer of Code projects, and we cooked up lots of new features. All the stuff that our GSoC students blogged about months ago and much more will finally be released in January 2011 in Amarok 2.4.
But first, to make Amarok 2.4 rock-solid we would like to ask you, our users, for some help.
We have just released Amarok 2.4 Beta 1, codename “Closer”. In the hope that this release brings us all closer to creating the perfect music player, get it, play with it, test it, and if you find something that needs to be fixed please do send us bug reports at bugs.kde.org.
If the next few weeks are holidays for you, the Amarok team wishes you a happy holiday season!
Remember a year ago when I blogged about the Social About dialog? The dialog in Amarok that replaces the dull old About dialog with something more colorful?
Last Wednesday, after an almost complete rewrite and a few days of review, I committed my KDElibs port of the Social About dialog to trunk, to be released with KDE SC 4.6.
What does this mean for end users?
The Social About dialog is a small built-in Social Desktop client, available in any KDE application. Its purpose is to bridge the apparent gap between users and developers by providing an additional communication channel right inside the application. As a user, you will be able to see some more information about the project’s contributors, and directly access a contributor’s online presence as exposed by openDesktop.org or another provider which implements the Open Collaboration Services (OCS) API, as chosen by the authors of the app.
Looking back at the time when I wasn’t a KDE dev I can distinctly remember that I used to perceive KDE contributors as a reclusive and elite clique of people somewhere far away, with mad skills, encircled by an aura of awesomeness. While I can testify that a lot of KDE people really do have superpowers, I’d hardly call them reclusive. To quash that misconception, I’m giving you, the user, a way to get to know the people behind the project. You might even be surprised to find out that there’s an active bunch of KDE hackers in your very city or that the authors of your favorite KDE app share your taste in music.
The Social About dialog replaces the old “About Project” dialog and exposes the Social Desktop features if all of the following conditions are met:
- You are running KDE 4.6 or later
- You have a working internet connection
- The contributors of the application you are using have chosen to add their usernames for an OCS provider such as openDesktop.org.
For every contributor who wishes to share his OCS data the dialog shows fields such as location, blog, homepage and social network profiles including Facebook, LinkedIn, Last.fm, Twitter and several others.
If there’s no internet connectivity or if a contributor does not wish to expose his data on the dialog, the appearance of an item will be very similar to how it was in the old offline about dialog.
What does this mean for application developers?
The general idea is to convey the message that the project is developed by real people, with another channel of user-developer interaction right inside the app.
This is a drop-in replacement for the old KAboutDialog. Obviously if you don’t touch anything in your KAboutData the dialog will be very similar to how it used to be, aside from some minor cosmetic differences i.e. you need to opt-in to use it. The dialog will also be in offline mode if KDElibs is built with the mobile profile (which is expected to remove the Attica dependency). By default, the Open Collaboration Services provider is openDesktop.org, and the contributor’s usernames can simply be appended to the KAboutData::addAuthor and addCredit calls.
In Amarok the experience has been positive, and there have been no instances of abuse (such as bug reporting in the wrong place or harassment) that I know of that could be attributed to the communication channels exposed by the Social About dialog.
If you already have a profile on openDesktop.org (or another OCS provider), don’t forget to update it before adding your username
Why was this an almost complete rewrite?
For several reasons. At the time I wrote Amarok’s Social About dialog, Attica (the library that talks to the Open Collaboration Services API used by openDesktop.org and other providers) was still a moving target, and I needed to throw away some of the code that used now deprecated and removed API elements. Also, Amarok’s Social About dialog couldn’t work as a drop-in replacement for the old KAboutDialog since the data structures used by Amarok’s Social About dialog were a hack designed to make the it work with an unmodified KAboutData and OCS usernames thrown on the side. Finally, the persons list in Amarok’s Social About dialog was just a bunch of widgets in a layout, and lacked many of the performance and reliability advantages offered by the new dialog which uses model/view.
I wish to thank Frederik Gladhorn for his useful suggestions and review, the Amarok team for their useful suggestions and support in surviving git-svn and the developers who reviewed my submission on KDE’s Review Board for their patience, attention to detail and help.
Aside from some minor planned improvements under the hood, the most prominent missing interface elements are about a dozen icons that represent links provided by OCS, such as Facebook, Identi.ca, LinkedIn and other social network profiles. We already have some of those from Amarok’s Social About dialog, but I still have to check if inclusion in KDElibs would be possible because of licensing restrictions, and what do KDE artists have to say about the appearance of said icons in the context of Oxygen.
And obviously, we are missing the data, so if you are a contributor for a KDE application and you feel like joining the Social Desktop bandwagon, go ahead and add that username!
While lots of new features are still pouring in from this year’s Google Summer of Code projects, it will take us a while to make sure they don’t crash and burn and hopefully release them some time later this fall. In the meantime, why don’t you help us weed out some bugs to make Amarok 2.3.2 the rock solid release we would like it to be?
To make the task easier, we have deployed a sentinel to look out for bugs: Amarok 2.3.2 Beta 1, codename “Sentinel” is out.
Since the last release in the 2.3 series the Amarok team has been working through the laziest days of summer to implement very much needed fixes, changes and even some new features, especially concerning filtering and podcasts. Read the full announcement here and don’t forget that to make Amarok 2.3.2 even better, bugs.kde.org is the place to be
It’s been GSoC season for over a month now and I haven’t blogged, so now I’m going to try to fix that. After last year’s Multilevel playlist sorting project, one of my proposals has been accepted again for GSoC 2010: I’m going to implement on-the-fly transcoding in Amarok.
Amarok is a music player and manager built around very general concepts of tracks and media sources. The collection tries to decouple the format from the data itself and presents the music as tracks (with metadata) rather than files. In other cases, music isn’t even stored in local files. These concepts, and others, allow one to truly rediscover music through seamless internet sources and media devices integration, and the user in fact doesn’t have to care where the actual data comes from. The many sources at one’s fingertips are accessible in a consistent way and playable from the playlist.
However, even in this day and age of stuff in the cloud, there are situations in which the user still has to worry about media formats, e.g. when acquiring new music, or copying existing music from one collection to another or from the collection to a portable music player. That’s where transcoding kicks in.
For example, one might have a quantity of Windows Media Audio files that should be transcoded to a more Free format in order to be usable in the future, or a quantity of Monkey’s Audio files, which, while lossless, are not well supported everywhere, especially in PMPs. And then of course, even if someone has a collection full of FLAC files, which is a reliable and Free codec, a conversion into a lossy format such as Ogg Vorbis or MP3 might be necessary for use with a PMP simply for reasons of storage capacity.
So my idea is this: whenever the user can copy files, give him or her the choice to either just copy, just transcode or transcode with custom options. That way, we cover both of the following use cases:
- “I’m running late for a 4 hour train ride and I haven’t updated the music collection on my portable player, I need to quickly copy over my tunes while making sure they will compatible with the portable player”
- “if I tweak the quality rating of the Vorbis encoder exactly the way I want it I’m going to save 1% of the space on my portable music player and still get the audio quality my sensitive ears deserve”.
The current situation is that the transcoding operation (in the strictest possible sense) works, so the next thing I have to do is integrate it nicely with Amarok’s existing collections framework. The current implementation uses FFmpeg, but I’ve placed FFmpeg-specific stuff in a wrapper class so something else could quite easily be used in the future if need arises.
The following screenshot represents the current state of the still quite unfinished transcoding GUI.
On a somewhat unrelated note, I’ve been to the KDE Multimedia+Edu sprint in Randa, Switzerland.
It was a lot of fun and very productive too. I wish to thank the whole organizers team. Special thanks go to Mario Fux for his mad organizational skills, to the cooking team which I had the pleasure to share the kitchen with while preparing vegan stuff and to Knut Yrvin for arranging a much needed meeting with the Brisbane office of Nokia, Qt Development Frameworks regarding QtMultimedia and the future of Phonon. Finally, thanks Anne-Marie Mahfouf for a gift she gave me which allowed me to taste again something I like very much but haven’t been able to eat because of nickel allergy.
Amarok 2.3.0 has just been released but the Amarok team is already working hard on the next release. Shortly after mainline opened for feature commits I pushed a feature that will hopefully result in the next Amarok release being based on user feedback even more than 2.3.0: LikeBack integration.
What is LikeBack?
Short answer: a client-server system for gathering context-related, anonymous and immediate user feedback.
Long answer: described in a blog post by Valerio Pilo, KMess developer.
Pics worth more than 1K words (hint: the icons in the top right corner):
In Amarok the LikeBack bar is enabled by default only for testing releases i.e. git builds and betas. When the user has a good or bad experience, or gets an idea for a feature, he can click on one of the icons in the top right and submit a message. With LikeBack we gather comments of the types “like” “dislike” and “feature idea”, single and short suggestions, not discussions or bug reports. Bugs are still handled through the usual dialog that takes the user to bugs.kde.org, a system much better suited for bug tracking than LikeBack: this also means that if we receive something like a bug report under the guise of a “dislike” through LikeBack, we will have to consider it invalid.
The feedback we have received so far (several dozen comments in half a week) is quite positive, no insults yet (yay!).
LikeBack is available in Amarok’s git mainline (and in git/nightly builds if your distro provides them) as of a few days ago (*not* in the 2.3.0 release), so feel free to give it a spin and let us know what you think, either through LikeBack or the usual channels.
The Amarok team is always at work, aiming with every release to deliver the best music player on earth and beyond. For some it may be just great fun, for others it may be a sacred calling, but for all of us a release cycle is a journey with its ups and downs, that comes to an end with a release. Each release is a time when we unleash our brainchild into the wild, and take a moment to just feel proud about what we have achieved.
This is such a moment.
Today I’m happy to announce the immediate availability of Amarok 2.3.0 “Clear Light”, which brings countless improvements and fixes over Amarok 2.2.2, and lots of new features. This release is the result of extensive user feedback, and it contains many patches submitted by members of the greater Amarok and KDE community. Check out the release announcement and please digg it.
A few months ago I submitted my work for the Social Desktop Contest, organized by Frank of openDesktop.org. As you may remember, my submission was the social about dialog for KDE apps, currently only in Amarok, but I hope to move it to KDElibs when my university thesis work, my work work and other IRL stuff gives me a break.
Turns out, lots of people seemed to really like it (thank you for voting!), and it won the first prize, which was a Dell Mini 10v netbook with Ubuntu – a really great and appropriate gift for a Free Software contest.
Unfortunately Dell has a really weird way of doing business, long story short, regardless of the free movement of goods inside the EU, because of Dell’s arbitrary business choices it was virtually impossible to ship the netbook from Dell directly to me in Italy. Anyway, Frank and I found an alternative solution with me placing the order on Amazon.co.uk, and a few days ago I received an EeePC 1008HA (they didn’t have the Dell Mini 10v). The netbook market has changed a lot since its beginnings and nowadays it’s very hard to find a netbook without Windows, this one was no exception as it had the Microsoft tax on its price and that ghastly Windows license sticker on its underside. I hoped to get back the cost of the license, mostly for ethical reasons, and I hoped that Amazon.co.uk would do the right thing as described here, but a few weeks ago I picked up some random report on Slashdot about Amazon now refusing to cooperate in honoring Microsoft’s EULA, which made me worry a bit.
After I got the package, I just sent a polite message through the official Amazon.co.uk support channels, and at first, I got a canned response from a support guy offering me a full refund for the netbook. When I replied kindly requesting that they actually read my message, the support person replied with an e-mail full of apologies and offered me a ~30€ refund for the Windows license, without asking any further information or proof of any kind. I wouldn’t bet that the 30€ bill made it all the way to Microsoft through Asus, but I hope that if enough people bother Amazon with this, they might eventually poke Asus. So, including shipping and after the Windows refund, this netbook cost about the same as the Dell Mini 10v with Ubuntu would have, and it’s an awesome little gadget.
I’m running Archlinux on it, installed with the Chakra live distribution (the latest Archlinux live USB stick image isn’t recent enough for a confortable installation on this hardware), but I removed the stable (and awesome) KDEmod packages to replace them with packages from a KDE SC 4.4 snapshot repo. Hardware support under GNU/Linux is great, aside from the wired ethernet adapter which required some tweaking but it works now. Battery life is incredible. I had no trouble getting used to the keyboard, which is quite good, but the touchpad buttons are hard and they make middle-clicking difficult. The Atom N280 based system feels reasonably fast.
I want to take this chance to thank Frank Karlitschek for his hosting of the OCS contest and his help and cooperation.
Thumbs down Dell for actively refusing to do business like any decent internet store in the EU, and thumbs up Amazon.co.uk for cooperating with me in exercising the rights that the Windows EULA grants me.
A few years ago when I still wasn’t an Amarok developer, the development team appeared to me like a bunch of uber-l33t geeks with mad sk1lls locked up in some ivory tower, performing their arcane incantations. Obviously it’s not the developers’ fault, the issue was that no matter how hard you try to reach out to the wider community, there is always a not so blurred line between users and developers, and this social distinction raised the barrier to entry for me probably even more than my lack of coding skills did.
I’m trying to change this, by bringing the Social Desktop to one of the most prominent places where users learn about the development team of a program: the About dialog. By tying some openDesktop.org profile data into a modified KAboutBox, it’s much easier to convey the message that the project is developed by real people, with a new potential channel of user-developer interaction right inside the app. For users, the advantage is that developers are now easier to reach, and I also hope that this might increase the quality of the communication by making some potential trolls realize that they are not talking to nameless nicks on IRC. For contributors, this might also be a nice recognition of their accomplishments: many of us do this unpaid, for fun and for love, and it’s nice if at the end of the day one can at least get a pretty dialog with a picture and a few rows of credit.
But what does “integrating Social Desktop features” really mean? Well, it can mean everything and nothing, in this case it means a new dialog called ExtendedAboutDialog for lack of a better name. Contributors have additional extended entries with data downloaded from openDesktop.org that can be viewed if the user has internet access and an openDesktop.org account. The About dialog becomes a small social desktop client.
The implementation is currently based on Amarok, but I’m keeping it as generic as possible. It uses the OpenCollaboration Services API, through the Attica library. Attica is a library, not yet independent, as I understand originally developed for the OCS dataengine and currently in kdeplasma-addons. Though the dataengine with Attica is already in 4.3, the Attica library may land into KDE 4.4. Until then, I have crudely copied over libAttica into Amarok’s source tree.
This dialog is already integrated in Amarok’s master branch on Gitorious, and my work on this about dialog can be tracked on my Gitorious page http://gitorious.org/~teo.
What follows is a screenshot of the dialog on startup. We can’t try to download data right away because the user has to sign into openDesktop first. So we just show the old style credits, with a button on top.
When the user clicks on “Connect to openDesktop…”, a login dialog appears and the data is fetched from openDesktop.org. Meanwhile, authors who don’t wish to use openDesktop.org are already added to the list.
Finally, when the data has been downloaded, the list is completely populated.
This works for contributors without author status too, with the profiles being shown in a thinner format to save space.
This dialog is still a moving target, and I’m posting quite regular updates and screenshots on its openDesktop.org entry.
When I started working on my proposal for what would eventually become my Google Summer of Code 2009 project, I was a much less skilled coder with no experience on something as large as this project turned out to be. I’m not bragging about becoming so insanely wiser now, but I have certainly gained tons of valuable experience, learned a lot about software development, and had a great time doing it!
So what exactly have I accomplished this summer?
Those who have been following my updates might remember the first part.
Well, the initial idea was to implement multilevel sorting in Amarok’s playlist, with a nice GUI, and throw in configurable grouping if there’s time. However right from the start it was clear that much more invasive changes were needed. As I already mentioned, Amarok’s playlist uses Qt’s Model/View design pattern. When I began working on my project the playlist had a source model (a class which feeds the rows), a filter proxy model (which filters out some rows that don’t need to be shown when a filter is active), a grouping proxy model (which decides which tracks should be grouped together because they belong to the same album) and finally, the view. Ideally, each model should talk only to the model right below it (if any), and the view should only talk to the “topmost” model to avoid any screw-ups in row presence and order. Failure to enforce this results in spaghetti code, which is exactly what was going on in the playlist code at the time.
So most of my first GSoC month I spent despaghettifying these Model/View classes, so that the Playlist::Model feeds data only to the FilterProxy, which feeds data only to the GroupingProxy, which feeds data only to the view. During this despaghettification, I also added a new proxy model: SortProxy, which is the class that actually implements the multilevel sorting backend. A month or so later I also added another proxy, SearchProxy, by decoupling searching from filtering. So the final result, as I already mentioned, is Playlist::Model->Filter->Sort->Search->Grouping->View: 5 models and one view. Doing all this without Qt’s Model/View classes would have been *a lot* harder and much more chaotic. So by the end of the second month the playlist code was refactored and made much clearer, the right auxiliary classes had been associated with the right model or proxy (mostly the topmost one, GroupingProxy) and a simple testing GUI was in place for multilevel sorting.
For the GUI, I chose to adapt a familiar paradigm to a new use case, so I used a breadcrumb path based widget. A sort scheme is a progression of levels, which represent sorting criteria, and those are applied to the playlist in real time. What’s even better, sorting is not an action but a state, which means that the original sort order can be recalled at any time. One of the sorting levels is also “Random”, so almost for free this interface also implements configurable multilevel shuffle!
In the last weeks, which were quite busy, I implemented configurable grouping, so the user is no longer forced just to group by album or not group at all. Finally, as a bonus, I took advantage of the existing Amarok URL infrastructure to implement playlist view bookmarks. These bookmarks define a URL for each playlist configuration, which aggregates a sorting scheme, a grouping category, a playlist layout and a filtering expression, and store it in the bookmark manager. The user can then instantly apply these bookmarked states and avoid having to rebuild a sorting scheme, a grouping category, select a layout and enter a filter string manually.
Playlist view bookmarks make it much easier to control this mighty playlist, which will be landing on a GNU/Linux distribution near you with Amarok 2.2 some time this fall!
I’d like to take this chance to thank my GSoC mentor Nikolaj Hald Nielsen and the whole Amarok team for their patience, dedication and help.