Amarok Blog

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.

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

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.

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.