Tomahawk, KDE, and other stuff
Amarok
Introducing the Popup Dropper
20About a year ago we had an issue in Amarok 2 development because we wanted to be able to move portable device track access into collections (this is happening with Alejandro’s GSoC project), but we couldn’t figure out a good paradigm for accessing the various device specific functions. There were some other concerns too, about the right-click menus getting too overloaded, making it hard to find common functions. Finally, when people wanted to drag music to the playlist, they now had to cross the entire window, whereas before it was a quick drag and drop…a lot less mouse movement, and possibly the difference between picking the mouse up and not.
So I had a brainstorm. We have this ginormous context view area in the middle of A2. What if we could put it to good use, and allow it to act as a surrogate menu? For many people, dragging the mouse a bit to drop items on a big target is much easier than navigating small right-click menus, where it’s easy to overshoot your destination and accidentally close submenus. Thus the PUD — the PopUp Dropper — was born. My first sketch of it is here:
(Here’s the preceding page that talks about collection groups. If you like that idea, be sure to let us know at ama...@kde.org.)
The PUD actually lived for a long time in the Amarok source tree, but there were problems. One was that it tied in too tightly to the existing Amarok context view code — something that, as that code was refactored over and over again, was painfully obvious would not work. The other was that the actual popping up and drawing was painfully slow. It seems drawing a QGraphicsView on top of another one wasn’t making Qt happy. Fortunately, as of Qt 4.4, this problem has been solved.
The final nail in the coffin (related to the first one actually) is that some of the people that saw the work wanted to see it available for all of KDE to use. This approach wasn’t going to work.
When Qt 4.4 hit qt-copy, I started to play around with things again. Soon enough I was addicted to making it work. I took the Drag ‘n Drop Robot example and started modifying it to use the PUD library I was making. The goals: make it Qt-only, make it very customizable so it could work in any situation, and make it actually able to replace a right-click menu.
I’m happy to say that those goals have been met. Here’s a list of current features:
- Runs on top of any QWidget (theoretically, though not fully tested).
- Two ways of creating submenus: either call addOverlay(), which essentially gives you a "clean slate" that you start afresh, and that runs on top of the current menu when show() is called, or you create a second PUD and pass it into addSubmenu() on the first, which is quite similar to the way a QMenu would be constructed.
- Can pop or fade in/out with configurable fade timing on a per-submenu basis.
- Background color and transparency, as well as text, is configurable on a per-submenu basis.
- When the mouse leaves the PUD area, it disappears (or the top layer disappears, and keeping it outside makes subsequent layers disappear)…configurable.
- The PUD items contain a PUD action, allowing for both drops (which calls triggered()) and hovers (which calls hovered())…each one individually configurable, of course.
- The items are represented by a SVG element you pass in, along with a renderer (or the default is to use the PUD’s renderer).
- The items arrange themselves automatically (submenu offset is configurable).
- Many more things. All of them configurable (sense a trend?).
I really wanted to make a video available, but I could get neither xvidcap, nor vnc2swf, nor captury working at all. recordmydesktop worked, but interfered with the drops, so it wouldn’t work as intended. Instead, I’m making an "alpha" version of the PUD available for people to see (I had been using a local git repository, which is included in the tarball). Don’t worry…despite me calling it alpha, it’s quite stable (in fact, as you’ll see, it’s already used in Amarok). No dependencies are needed, just qmake the dragdroprobot.pro file, make, and run the dragdroprobot file. Caveats: it’s not commented (see coloritem.cpp for usage examples), I know of a few bugs, it’s not finished (I have several more things to add to it), there is at least one crash that I can’t reproduce reliably and have not found, there are some things I need to test but have so far been unable to (such as more than one submenu layer), and note the copyrights and distribution requirements on the files — it’s a modified example from Qt. Preferably run in a Qt 4.4 environment (i.e. in a KDE trunk login) to get all the benefits of Alien, or else it might be rather slow depending on your system. But with that all said, let me know how you like it.
Finally, it’s been updated in the Amarok source tree. Now that I got the submenu support working, Nikolaj has gotten it integrated. In recent builds of Amarok you can simply start dragging an item from your collection and see it in motion. Some screenshots follow. The first is showing the normal menu, the second shows the submenu that pops up when you hover over the Organize Files item (you can see the previous menu behind it, through the transparency).
So what’s next? Hopefully, this will eventually make it in some way shape or form into kdelibs, assuming the API stays stable (it was written in the kdelibs style, with a d pointer and private classes), making it easy for KDE apps to take advantage of it without being an external dependency. And as it gets completed I’ll be making it available separately for any Qt app out there that wants to use it (not sure what license it will be under…either GPL or BSD). For now, if you want to see the latest versions, keep your eye on the Amarok source code in the src/popupdropper directory (it has a few modifications to my "master" source simply to make it build in the Amarok source tree…specifically, adding moc file includes since it’s not using qmake, and exporting PopupDropperAction).
Comments appreciated!
Amarok SoC: Media Devices + Awesome iPod support
10Introducing Alejandro Wainzinger (xevix on IRC), who is going to be working on media device support in Amarok for SoC 2008:
My name is Alejandro Wainzinger, and I’m going for a Computer Science B.S. at the University of California Santa Cruz, USA. This summer, I’ll be bringing back media device support to Amarok for Apple iPods, MTP and generic devices, and making them fly. I chose this project because I own an iPod, and got frustrated with the speed of loading an iPod with a large database, sync’ing of songs/playlists and album art, unlogged crashes after trying to put a 10,000 song queue onto the iPod, and slightly unreliable iPod model detection. That said, I loved having iPod capability in Amarok, and I couldn’t see Amarok 2 without media device support.
Alejandro is going to work on getting normal functionality for all three types of devices, and then really taking the iPod plugin to town.
Rumor has it he’s then going to attempt making collections out of the devices…
Go Solid Go!
11I’ve been rather silent on the topic of progress in media devices. Part of this is that much of the work has happened behind the scenes. Just yesterday I spent hours editing device definitions in libmtp and libnjb so that they’d be able to propagate the correct vendor and product info through hal, because hal’s handling of it leaves something to be desired. For instance, on my Creative Zen MicroPhoto, it correctly detected the vendor and product. Except that the part of the device detected as a portable media player was the USB interface for the device, for which the vendor was blank and the product name was "USB Interface."
Another reason for the long delay was a partially failed experiment that aimed to provide support for many different media devices via a centralized kioslave. It’s not that this couldn’t still happen, at some point, but it becomes extremely difficult to map protocols that have no notion of filesystems into a filesystem, and have filesystem clients behave properly. There was another foray into a different system that also ended badly — mainly because there was no way I’d get it finished within a year, much less within a few months.
In the end it was decided that Amarok’s device plugin system is really pretty decent, providing relatively bug-free and easy device management for almost every device on the market…and if it ain’t broke, don’t fix it. Of course, it’s using tons of deprecated classes and methods, but as Trolltech says (my emphasis), "we recommend against using these classes in new code." Good point. So let’s get stuff working, and then we can try to design a new, better system in parallel — but at least something will work in the meantime.
So with that decision made, I worked on integrating with Solid. I’m happy to report that today, I plugged in my Creative Zen MicroPhoto, and it was instantly detected and the correct plugin selected. All I had to do was hit Connect. Screenshots:
The first screenshot shows what the media browser looks like with nothing plugged in. At that point, I plugged in my Creative Zen MicroPhoto, and you can see that it was detected and added to the device selector drop-down box:
After this, I hit the Connect button (it’s the one on the top left) and artists were displayed. I hit the custom button just so you could see some of the details available:
So it’s coming along. I expect this device detection to work on pretty much any kind of music player (except generic/vfat/UMS…more on that on a later post, when I have time to work on it), provided that:
- hal is installed and working.
- You are using a recent version of libmtp/libnjb for those devices. I’ve also worked with libkarma and libifp but have been unable to actually check them out to see how they’re working since I don’t have those devices. We’re probably going to start a "send us your old media devices" thing going, so that I can work on all of them. libgpod was more hesitant about working with me, but there’s a problem there anyways, as apparently you can’t detect from the USB interface the iPod exposes what kind of iPod it actually is, without connecting to it. Feel free to blame Apple on this one, as it’s probably on purpose in an attempt to keep you on iTunes. So there’s a generic definition already in hal which should be (hopefully, pending testing, send me your old iPods) good enough to at least have it show up as an iPod. Once you click the connect button the library should be able to provide more info.
- Your distribution’s package of the device access libraries installs the hal fdi files provided by the libraries. For some unfathomable reason many (most?) don’t — even my beloved Gentoo. So start bugging your package maintainers early, because if you don’t have these installed, you’re not going to get autodetecting goodness. Some of these may end up in the main HAL distribution (I have repo access so can add them in) but for many it doesn’t make sense as they’re constantly being updated or changed, and it would require changing in two places instead of one. (Also, some libraries generate these automatically, instead of having a fixed file).
So that’s it for now. The next step is to get manual adding of devices working again. And after that, dealing with generic devices in a smart way (the way will be Banshee-compatible too…thanks to Aaron Bockover for the excellent idea!) In the meantime, watch out for the Amarok Device Donation Program. 
Device Handling and HAL
1My blog’s been rather inactive for a while. Most of this has been because of being busy, and because of not doing hugely exciting things when I have had Amarok hacking time (mainly some bugfixes in stable branch). But now something’s come along that warrants an entry.
Amarok’s device handling is pretty adequate. Granted it could be better, but we support nearly every device on the market through some plugin or another. But there’s one recurring problem: except in a few cases, Amarok doesn’t know what device you have plugged in, and how to handle it. You have to tell this to Amarok. This means you, and we, have to deal with the manual creation of devices. Well, that’s going to change.
Enter HAL, and its KDE4 paramour Solid. By now, you probably know what these do. HAL, Hardware Abstraction Layer, gathers information about your hardware. Solid reads it (and some other information) and outputs a KDE interface to it. Now by itself, this isn’t enough, because HAL has a namespace called portable_audio_player, but, with a few exceptions, it doesn’t actually say what type of device you’re using — simply "storage" for a USB Mass Storage interface, or "user" meaning that a userspace library needs to handle it.
However, for the last few weeks I’ve been working with HAL developers and the developers of libgpod, libifp, libkarma, libnjb, and libmtp. The goal has been to come up with a way that device access protocols can be auto-detected. If you know what access protocol a device uses, you can load the appropriate plugin automatically. Well, this has been done, and as a result the HAL portable_audio_player namespace spec is being modified to allow libraries to insert information they know about devices into HAL — while at the same time keeping libraries from clobbering each other. Interested parties can find a draft version here, with the final verison going into HAL as soon as the slugs at freedesktop.org set up my account.
After this, I will be adding proper entries in libmtp and libnjb (easy, since I have commit access for both), making entries for libifp and libgpod, and working with the libkarma developers for their entries. After all this is done (probably in the next couple weeks), Amarok 2.0 and other HAL-aware clients should be able to determine and load the correct plugin for just about any device on the market, automatically. Okay…after a lot more hacking on 2.0…but you get the picture.
I’m hoping that when this is done we can remove manual device addition/deletion. It’s a complex part of the code that can be difficult to maintain, and shouldn’t be necessary any longer — if you have a library that can handle the device that Amarok can use, Amarok should already know about the device from HAL. Even generic USB Mass Storage players should be fine, because they should be detected by HAL and exported through Solid as storage volumes. The only thing I can see this affecting negatively is the generic device plugin that just got fixed to support arbitrary KIO paths but I’ve been thinking about pulling that into the Collection some way anyways, now that the Collection can handle many sources, as this would let it handle *lots* of sources
Amarok on Mac
17Been a while since I posted, but I thought I’d give you guys a glimpse of a (very ugly) Amarok running on a Mac. I used the excellent packages from Ranger Rick to get KDE4 libs up and running (you can do it from svn but many of the tools required are most easily gotten from Fink, which can cause conflicts if you have kde3 stuff from it).
I can’t get database support working yet, but it does build and run. Check it out:
Bang, bam, boom
1I’ve been knocking down my to-do list like there’s no tomorrow. I posted recently about the VFAT device rewrite; it is now complete and early testing results seem to be positive (it’s been renamed to "Generic Audio Player" by the way). In addition, ATF backend support should now be fairly complete. I’ve been debugging it for a while and everything seems to work well now. It catches file copies, moves, and renames, and lets you assign new IDs to files through a DCOP call. It doesn’t slow down scanning much either (I’ve been scanning 2082 files in about 30 seconds or so). I have yet to test it on Oggs, but I would imagine that it’d be fairly simple to get that working too.
The next hurdle is actually making amaroK components use ATF. I don’t think that will happen in time for 1.4 final, but in the point releases thereafter hopefully you’ll start to see some components take advantage of the features that ATF provides, to help it really live up to its name.
More on the VFAT rewrite
18The VFAT rewrite continues apace (it may get renamed for 1.4 final). Many functions have now been implemented, and far from scaring me, I now feel quite comfortable with the code I’ve written. Just goes to show how taking a fresh perspective can really make a difference. It should be working much better than the previous incarnation of the plugin once it’s done, and hopefully folks using 1.4 final will be happy with it.
Karma!
7While updating my box at work today to kernel 2.6.16, I noticed that it now has support for Rio Karma partitions. This rocks, as the Karma is a very capable player that can play FLAC (and I think Ogg Vorbis) in addition to MP3, but previous had no Linux support. I’ll have to find a time to grab my girlfriend’s Karma and give it a go…if she lets me…
VFAT Rewrite
1ATF stuff has taken a backseat for a bit while I rewrite the VFAT device plugin. Originally I had ported the code over from the ifp media device plugin…the problem is that to deal with the differences between the two kinds of devices the code quickly became full of hacks. Changing one thing meant five other things broke…a bad situation. I’ve known for a while I would need to redo it, but I was procrastinating because I hated working on it so much, but now that we have a planned release date for 1.4 final, well, I figured it was time to get it over with.
The good news is that this time, I’m not hating it as much. This is mainly because I’ve started with a much more hierarchial design that makes tasks that were complex and error-prone in the old device code much more simple and reliable. The end result should be a device plugin that is much more stable and doesn’t have as many weird quirks — with any continuing quirks fixed quickly, of course!
Today I got done with enough code to display the filesystem and allow for expanding directories. This may not sound like much, but it’s actually a good sign, as these functions seem to work well and stably, and these basic functions being completed means that all the under-the-hood code is working (which was the majority of the rewrite), so the rest of the functions will be easy to implement. And the best news of all is that unlike the old code, I’m very confident in this new code!
Rip your CDs with KIO and amaroK
13Yesterday I commited some code to the Collection Browser that allows it to accept URLs with the audiocd:/ protocol. If your machine supports this (the audiocd:/ kioslave is probably in the kdemultimedia package), you can rip by doing the following;
- Open KControl. Go to Sound and Multimedia->Audio CDs. Configure your ripping preferences.
- Open Konqueror. Go to audiocd:/
- Go into whatever folder you want your tracks encoded as, i.e. Ogg Vorbis will contain Vorbis "files" that you can select.
- Drag these tracks to amaroK’s Collection Browser.
amaroK will perform a KIO copy, which will result in a seamless rip of the track and import of the track into your collection. Easy as pie, and using KDE’s built-in capabilities to boot!
Recent Comments