Amarok Blog - stecchino

Apple breaks Palm Pre compatibility. Or: an open letter to Palm

nospam@example.com (Bart Cerneels) — Thu, 16 Jul 2009 18:52:02 +0000

Dear Palm,

When you launched the Pre everyone was very excited about the excellent job you did. Everyone except Apple that is, they don't like such strong competition.

You decided to reverse engineer the iTunes database "protocol" used in Apple products and implemented it from the device side on the Pre. This has the benefit of being able to sync the Pre with iTunes on any PC or Mac without installing extra software.
And you didn't have to invest in development of your own desktop software, which is not a differentiating feature for you. You're in the business of selling phones, not software. I don't think deciding to "outsource" this to Apple was a smart move though.

So now the bully is attacking you on their playground:

From Engadget Mobile

And then they say it's your own fault. You could go crying to the principle (or whatever you want to call court you want to file the anti-competitive lawsuit with).

But if you have a problem, if no-one else can help, and if you can find them, maybe you can hire the AMAROK-TEAM!

The media-player support in Amarok 2 is shaping up to be very flexible, complete and easy to implement thanks to the hard work of 2nd time GSoC student and hacker extraordinaire Alejandro.

We can quickly add support for the Palm Pre, or any other player, providing there is a way to access the database and we have documentation of the data-format. We already have iPod and MTP support and the same system is used to implement audio CD as a collection. iPhone OS 3.0 is being worked on as well as UMS (generic USB device) and OBEX (many cellphones).
We promise not to change our application to prevent users to use Amarok with your device. Not only do we care about our users, we are not a competitor to you or have any ulterior motives.
Amarok is already fully supported on all flavors of Linux and we have beta releases on Windows and Mac OSX which just need a bit of polishing and stabilization.

Serious business proposals can be send to the Amarok team at business@getamarok.com (these emails will not be publicly readable).

Amarok Junior Job: Auto-download new podcasts

nospam@example.com (Bart Cerneels) — Sat, 13 Jun 2009 11:32:02 +0000

A recent comment by progmanos on the post of the 2.0.1.1 release reminded that I still have to implement Podcast episode auto-downloading. In the hurry to get 2.0 released I did add the config option, but forgot to add the actual code to make it work.

In Amarok 2 Podcasts are implemented in classes derived from PodcastProvider. There can be mutliple providers, which allows for instance podcast syncing between Amarok and an iPod.
The default provider is SqlPodcastProvider. This is where the auto-download function should get implemented.

This is a nicelly contained and not to steep introduction to Amarok development. So it's an excelent Junior Job.
If progmanos or anyone else would like to have a go at it, contact me on #amarok on irc.freenode.net. My nickname is Stecchino.

UPnP DevSprint in Paris

nospam@example.com (Bart Cerneels) — Sat, 13 Jun 2009 11:32:02 +0000

Hi from Paris, where together with [ade], dev, erwan, philn and lightyear I'm at the Coherence/KDE developer sprint focused on UPnP.
Yesterday, after struggling with QtDBUS (specifically the under-documented qdbusxml2cpp) I managed to the signals from Coherence and call functions. So now I can discover the devices on the network.

The signals are connected to a UPnPCollectionFactory that should create a new collection for each mediaserver (containing music) on the network.

Next step will be to really talk to the devices themselves. That will require some XML parsing, which can get a bit complicated. With any luck I'll find a Qt based DIDL-lite parsing library. Consider that a lazyweb questions .

A bientôt,
Bart

UPnP support in KDE and Amarok

nospam@example.com (Bart Cerneels) — Sat, 13 Jun 2009 11:32:02 +0000

During FOSDEM [ade] and I met with Frank Scholz, the lead developer of Coherence. We discussed DLNA/UPnP and how Coherence can be used in KDE and Amarok. The conclusion of this meeting was that we should use Coherence as our base for supporting UPnP services in KDE. The first implementation will be a KIO slave for browsing media stored on remote devices.

UPnP is a network technology using a combination of SSDP, XML and SOAP, with some GENA thrown in for eventing. A group of UPnP services called the UPnP A/V Architecture has been picked up by an industry organization called the Digital Living Network Alliance. DLNA specifies device classes which have to implement specific services and support a minimal set of filetypes and codecs.

Coherence is a framework, written in Python but it exposes a DBUS API, that allows an application to participate in the "Digital Home Network". For the moment this means mainly UPnP, but support for Ampache is available and Apple's DAAP is also considered. It's published under the MIT license and is multiplatform.

In Amarok we have been planning to integrate UPnP for a long while. But except for a failed Google Summer of Code project last year not a lot of effort has been spend. Thanks to Coherence this will quickly change: in relative short term (read 2.2) we will introduce a UPnP Collection that will list and enable playback of music stored on a DLNA Digital Media Server.

We could even consider publishing the content in the local Collection, basically making Amarok a DMS. Amarok can then track plays on remote devices and use it in the scoring algorithm.
Even more advanced functionality would be to control one or more Digital Media Renderes, such as
the Philips Streamium, from Amarok.

A few mails have been going back and forth between interested developers about discovery of network services in general. In order to simplify using technologies as UPnP, zeroconf, Samba, etc I'm wondering if we can integrate this in Solid. Only the discovery part obviously, using the services would be the task of separate frameworks, such as Coherence. With this functionality in Solid it should be trivial to show a kind of "Network Map" to the user with all the services per device.

As you can tell, plenty of cool things to keep a few people busy for a year or 3.

Bart

Amarok podcasting 2.0 and post-2.0 plans

nospam@example.com (Bart Cerneels) — Sat, 13 Jun 2009 11:32:02 +0000

Hey fellow developers and users,

In Juli 2007, at Akademy Glasgow I started implementing podcasting support in Amarok2. Since then I was sidetracked a little, as you may be aware.

The little time I did manage to spend designing and implementing was short and far from focused. So a lot of features are not finished or just plainly missing. The framework I created underneath suffered from the same lack of focus and is need of a good review. I'm aware there is probably some overdesign and some parts might be to complex. If you feel you can help in that area I suggest you take a look at extragear/multimedia/amarok/src/podcasts . Send questions, comments and suggestions to amarok-devel@kde.org .

The 3rd beta from Amarok 2.0 is already out the door and podcasting support is still not finished. In order to make it I had to reduce some goals I had set for myself during those rainy summer days in Scotland. Here's the plan:

Amarok 2.0:
The focus ATM is on finishing the SqlPodcastProvider, Podcastmodel and PodcastCategory (GUI).
SqlPodcastProvider uses tables in the standard SQL database, adds and updates the feeds using PodcastReader and downloads to disk using the regular KIO-jobs.
To make the podcasting fully functional though we'll need to reintroduce:

Autoscan the feed for updates
Download when available
Episode purging (delete downloaded episodes automatically)

The settings dialog for this exists, next up is using them .
The GUI currently shows all episodes ever read from the feed, which obviously needs to be addressed.
The GUI for 2.0 should be very similar, if not identical to Amarok 1.4, probably minus folder tree grouping support since that is better handled generically for all Playlists (which PodcastChannel is in our class diagram).

If anyone has a bit of Qt Model/View experience and would like to see podcasting in Amarok 2.0 I suggest you send a mail to amarok-devel@kde.org or ping me on irc (Stecchino on #amarok).
Without help we might have to drop it's from 2.0 completely because it's a bit much for me alone to complete and stabilize.

Amarok > 2.0:
I do have a plan for a complete GUI overhaul post-2.0. I'll get some art and usability advice in another blog post when the time comes.

The 2.x releases should see more advanced features being introduced that the framework is already designed to support:
For the SqlPodcastProvider specifically:

Renaming and sorting individual episodes (popular request)
Purging based on episode age and/or total size on disk
Labeling of PodcastChannels (perhaps to replace traditional folder tree grouping)

More general

Mediadevice Podcast support: iPod being the most advanced implementation but also generic usb devices, music phones and Canola2, I'm sure the INdT guys could help us with that.
OPML import and export
Podcast Directory personal subscription list.
BashpodderProvider: to use bashpodder and Amarok in parallel with synchronized download status
...

On to hacking.

UPnP DevSprint in Paris

nospam@example.com (Bart Cerneels) — Thu, 21 May 2009 05:52:02 +0000

UPnP support in KDE and Amarok

nospam@example.com (Bart Cerneels) — Thu, 21 May 2009 05:52:02 +0000

Amarok Junior Job: Auto-download new podcasts

nospam@example.com (Bart Cerneels) — Thu, 21 May 2009 05:52:02 +0000

Amarok podcasting 2.0 and post-2.0 plans

nospam@example.com (Bart Cerneels) — Thu, 21 May 2009 05:52:02 +0000

Autoscan the feed for updates
Download when available
Episode purging (delete downloaded episodes automatically)

Renaming and sorting individual episodes (popular request)
Purging based on episode age and/or total size on disk
Labeling of PodcastChannels (perhaps to replace traditional folder tree grouping)

More general

Mediadevice Podcast support: iPod being the most advanced implementation but also generic usb devices, music phones and Canola2, I'm sure the INdT guys could help us with that.
OPML import and export
Podcast Directory personal subscription list.
BashpodderProvider: to use bashpodder and Amarok in parallel with synchronized download status
...

On to hacking.

UPnP DevSprint in Paris

nospam@example.com (Bart Cerneels) — Sun, 10 May 2009 06:32:02 +0000

UPnP support in KDE and Amarok

nospam@example.com (Bart Cerneels) — Mon, 16 Mar 2009 17:22:02 +0000

Amarok Junior Job: Auto-download new podcasts

nospam@example.com (Bart Cerneels) — Mon, 16 Mar 2009 17:22:02 +0000

Amarok podcasting 2.0 and post-2.0 plans

nospam@example.com (Bart Cerneels) — Mon, 16 Mar 2009 17:22:02 +0000

Autoscan the feed for updates
Download when available
Episode purging (delete downloaded episodes automatically)

Renaming and sorting individual episodes (popular request)
Purging based on episode age and/or total size on disk
Labeling of PodcastChannels (perhaps to replace traditional folder tree grouping)

More general

Mediadevice Podcast support: iPod being the most advanced implementation but also generic usb devices, music phones and Canola2, I'm sure the INdT guys could help us with that.
OPML import and export
Podcast Directory personal subscription list.
BashpodderProvider: to use bashpodder and Amarok in parallel with synchronized download status
...

On to hacking.

UPnP support in KDE and Amarok

nospam@example.com (Bart Cerneels) — Fri, 13 Mar 2009 00:52:02 +0000

Amarok Junior Job: Auto-download new podcasts

nospam@example.com (Bart Cerneels) — Fri, 13 Mar 2009 00:52:02 +0000

Amarok podcasting 2.0 and post-2.0 plans

nospam@example.com (Bart Cerneels) — Fri, 13 Mar 2009 00:52:02 +0000

Autoscan the feed for updates
Download when available
Episode purging (delete downloaded episodes automatically)

Renaming and sorting individual episodes (popular request)
Purging based on episode age and/or total size on disk
Labeling of PodcastChannels (perhaps to replace traditional folder tree grouping)

More general

Mediadevice Podcast support: iPod being the most advanced implementation but also generic usb devices, music phones and Canola2, I'm sure the INdT guys could help us with that.
OPML import and export
Podcast Directory personal subscription list.
BashpodderProvider: to use bashpodder and Amarok in parallel with synchronized download status
...

On to hacking.

UPnP support in KDE and Amarok

nospam@example.com (Bart Cerneels) — Fri, 13 Feb 2009 20:12:02 +0000

Amarok Junior Job: Auto-download new podcasts

nospam@example.com (Bart Cerneels) — Mon, 02 Feb 2009 19:12:04 +0000

Amarok podcasting 2.0 and post-2.0 plans

nospam@example.com (Bart Cerneels) — Wed, 12 Nov 2008 11:22:01 +0000

Autoscan the feed for updates
Download when available
Episode purging (delete downloaded episodes automatically)

Renaming and sorting individual episodes (popular request)
Purging based on episode age and/or total size on disk
Labeling of PodcastChannels (perhaps to replace traditional folder tree grouping)

More general

Mediadevice Podcast support: iPod being the most advanced implementation but also generic usb devices, music phones and Canola2, I'm sure the INdT guys could help us with that.
OPML import and export
Podcast Directory personal subscription list.
BashpodderProvider: to use bashpodder and Amarok in parallel with synchronized download status
...

On to hacking.

Podcast appliance

nospam@example.com (Bart Cerneels) — Tue, 13 Mar 2007 18:57:09 +0000

Imagine a device dock, device in this case being a phone, iPod or any other media playing device, that is connected to the Internet and will download podcast episodes and put them on the device.

This piece of python code is supposed to run on an embedded device without storage. Just a small box that is connected to a docking station using USB. When a USB plug event is detected the main code queries the device specific Plugs for device presence. Podcasts are downloaded and stored directly on the device, without using any intermediate storage. When an episode is saved successfully it's status is saved in a database on the device. Listened episodes can be marked as such in the database. All configuration, database and storage is device dependant and implemented in a device plugin.

I can envision more capabilities like BitTorrent support and integration with web-services and maybe an Amarok script to sync the database.

The code is very rudimentary, only 2 plugs are implemented:

local storage plug: for testing purposes, can be reused for devices that can be mounted with usb-storage.
ObexFTP plug: I plan to use this for uploading podcasts to my cellphone. It still uses temporary storage until I add the necessary code to ObexFTP and OpenOBEX.

I haven't put copyright information in the files yet. Mainly because it is using a lot of other code and I haven't bothered looking at the licences. Feel free to use this code anyway you like.

I plan to use this code to upload podcasts to my phone from many different computers and embedded platforms without running any commands manualy. That means PodcastGrabber has to run as a service, listening to USB events, I might use HAL for that, but I doubt HAL is very useful on low-storage embedded platforms.

KDE4: actions menu

nospam@example.com (Bart Cerneels) — Tue, 13 Mar 2007 17:57:10 +0000

Task driven menu for applications.
Have a "actions" menu in every kde application containing the most common actions you can do with it. ex. Amarok: "Play Media", "Play Audiocd", "Quit". When using the desktop menubar the actions menu gets renamed to the application name. See my previous post to see why that is useful.
Every user is different so it could change the order of the actions menu depending on the users usage of those actions. It can even insert actions that are not there by default. I guess most items in a well designed menu can end up in the actions menu. The developers have to tag menu items as actions but only a few of them (most used or default) end up in the actions menu. And, since automation seems to be bad usablility wise (according to Ellen), users and developers are able to pin items to the menu.
If you are shouting "this is similar to XP's start menu or the Kickoff menu". You are right, only on a single application level and much finer grained.

In Amarok we had the problem that users weren't finding the features we worked so hard to invent and implement just about every release. This actions menu could help the discoverability of otherwise hard to find but wonderful features without bothering them with things like "tip of the day" or that damn paperclip.

Comments are welcome

Podcast appliance

nospam@example.com (Bart Cerneels) — Tue, 13 Mar 2007 17:45:12 +0000

Imagine a device dock, device in this case being a phone, iPod or any other media playing device, that is connected to the Internet and will download podcast episodes and put them on the device.

This piece of python code is supposed to run on an embedded device without storage. Just a small box that is connected to a docking station using USB. When a USB plug event is detected the main code queries the device specific Plugs for device presence. Podcasts are downloaded and stored directly on the device, without using any intermediate storage. When an episode is saved successfully it's status is saved in a database on the device. Listened episodes can be marked as such in the database. All configuration, database and storage is device dependant and implemented in a device plug.

I can envision more capabilities like BitTorrent support and integration with web-services and maybe an Amarok script to sync the database.

The code is very rudimentary, only 2 plugs are implemented:

local storage plug: for testing purposes, can be reused for devices that can be mounted with usb-storage.
ObexFTP plug: I plan to use this for uploading podcasts to my cellphone. It still uses temporary storage until I add the necessary code to ObexFTP and OpenOBEX.

KDE4: Backstage

nospam@example.com (Bart Cerneels) — Wed, 28 Feb 2007 18:33:10 +0000

The system tray is a limitedand valued realestate. Besides that it is extremely limited, smal icons make it hard to aim and actions can only be added in a menu, usualy right click menu, which is a problem all by itself.
But the problem is there are a lot of apps that use it as a mini taskbar. Like amarok, kontact, kopete, ... to many to name. And then there's superkaramba with widgets to control programs like amarok and other widgets to display feeds.
There's an opportunity here, what to do if programs want to remain running without a window open? Minimize them to the desktop as a widget. Of course this is not new, it's a concept used in CDE and probably others, they just create a icon on the desktop. But this is something different, so bear with me.

I call this concept Backstage, it would be a part of plasma and a there would be a framework to create Backstage widgets as easy as creating a system tray icon.

As example: the backstage widget for amarok

When sitting idle on the desktop and amarok is not playing the widget would look like the big amarok icon without the buttons.
If you move the mouse over the widget the actions swirl around the icon and stop where they are in the image.
When a track is playing the artist and title would rotate around it and the progress is visible by the percentage of the icon that is in grayscale.
Clicking on the action buttons does the expected thing, clicking somewhere else on the widget restores the amarok main window.

Practically I would implement this with animated SVG's for the graphics, Python for the behavior and DCOP for the communication with the parent application.

Off course the system tray doesn't need to dissapear completely but at least KDE4 apps that run in the background should have a backstage widget and let the user decide.

KDE4: Improved desktop menubar

nospam@example.com (Bart Cerneels) — Wed, 28 Feb 2007 18:33:10 +0000

I use the desktop menubar all the time. Mainly because it saves some vertical pixels on every window, very useful on my widescreen laptop. I looks cleaner to.
For those of you that don't know what it is. The desktop menubar shows the menu of the focused application (instead of in the top of the applications main window). It's a feature borrowed from MacOS.
unfortunately unlike in apple's OS the menubar doesn't contain the name of the application the menu belongs to. That creates some confusion for those not used to it and sometimes irritates me.

I suggest that in KDE4, instead of the usual "File" menu (or in amarok 1.4-svn "Engage") be changed to the applications name when using a desktop menubar. Actually, isn't File a bad place to put the quit item? Settings would fit better in there to. KDElibs4 should just rename the first menu to the application-name or just add a icon in front of it like in the screenshot. I guess a lot more people will start using the menubar then.

first post

nospam@example.com (Bart Cerneels) — Wed, 28 Feb 2007 18:33:10 +0000

The best ideas are common property.
Seneca (5 BC - 65 AD), Epistles

I agree with the ancient roman guy, thats why I'll post the idea's I get on the most impractical times in the most awkward places on this blog.

I'm Bart Cerneels, a.k.a. Shanachie, a.k.a. stecchino, a electronics engineer, free and open-source enthusiast and KDE hacker.

Want to know what goes on in my head when my eye's turn glazed and I reach for my notebook? Read this blog!