Thursday, August 14. 2008Responsible Disclosure, and Amarok 1.4.10Yesterday we released Amarok 1.4.10, an unanticipated security release. From the Release Anouncement you may notice that we gave thanks to Google Alerts for notifying us of this vulnerability. This was perfectly accurate. Read on for why. I want to say up front that the security value of this vulnerability rates so low that it's amazing Secunia even bothered with it. It requires local access (or at least, a shell prompt), and it requires our code parsing a file whose name was hardcoded to execute the code (doesn't)/overflow a buffer (doesn't)/do things incorrectly (doesn't). At worst, you could maybe make Amarok crash, and since this would be a race condition, you'd have to be extremely lucky, and this could only happen between when the user was downloading the Magnatune database and when it was being parsed. Not exactly mission-critical. So, the actual threat of the vulnerability was approximately nil. That wasn't the driving factor behind the sudden release -- the driving factor was the fact that since Secunia did issue an advisory, we wanted to respond to it as soon as possible. Which should have been 36 hours before. Here's where the bungling comes in. At midnight Tuesday morning, Dwayne Litzenberger posts a bug report on the public Debian bug tracker with snippets of code from Amarok, and the following: I'm not familiar enough with Qt to be sure, but it looks to me like the code creating a temporary file insecurely. At minimum, I think this code will break if another user has already created /tmp/album_info.xml (thus preventing the current user from deleting it). Now, I'm more familiar with the KDE and Gentoo bug trackers, which explicitly ask you to not post security related information there, but to contact the projects directly (this would be in following responsible disclosure guidelines). Debian's bug tracker doesn't seem to say this, but it's hard to say -- in a couple minutes of looking around, I didn't see a link that would let me file a new bug directly. It seems you have to either email it in in a certain format or run their reportbug tool. But as I was saying -- it gets posted to the public bugtracker, and Dwayne doesn't actually contact us directly. Neither does Debian. Perhaps they don't have bug triagers like I'm used to in Gentoo, and perhaps the maintainer of the package wasn't around for those 36 hours. Perhaps they simply didn't bother -- after all, we recently found out that Debian has created several patches for 1.4 over the years that their maintainer(s) never forwarded upstream. Mid-Wednesday, Ian gets a Google Alert for Amarok -- Secunia has issued a security advisory against us. This is how we first find out about it, which was apparently considered enough of a vulnerability for Secunia to bother with it. Dwayne didn't notify us. Debian didn't notify us. Secunia didn't notify us. No one bothered. This doesn't exactly correspond to normally followed responsible disclosure guidelines. A fellow developer thinks "Joe User" -- in this case Dwayne -- shouldn't be expected to know those guidelines. I don't buy it. If you know enough about security to recognize a vulnerability, you should know enough to properly disclose it. My fellow developer also thinks that Dwayne acted responsibly, letting the world know about the vulnerability as soon as possible so that users could arm themselves against the problem until it was fixed. This is wrong, and easily seen to be wrong. Let's forget for a moment that the vulnerability was miniscule in terms of threat level, and just think about it in terms of being a vulnerability, to prevent yourself from thinking "well yes, I see your point, but it was really miniscule" -- because that's not the problem with what happened here, and next time the vulnerability could turn out to be major. Had Dwayne notified us first, instead of posting on the Debian bug tracker and letting it lie:
By not following responsible disclosure guidelines, any users concerned about Amarok's security were unaware of, and running, unpatched software for at least a day and a half longer than if responsible disclosure guidelines had been followed. Far from letting the users know so that they could act to protect themselves, the users actually ended up being the ones getting screwed here. Now, I will say something in Dwayne's defense, on the off chance that he could spot a security bug but really didn't know responsible disclosure guidelines -- on their bug tracker, Debian has the following piece of information: Don't file bugs upstream: If you file a bug in Debian, don't send a copy to the upstream software maintainers yourself, as it is possible that the bug exists only in Debian. If necessary, the maintainer of the package will forward the bug upstream. In this case, the first "if" in that sentence should have failed -- it shouldn't have been filed in Debian's bug tracker. But even if the user decided they want to put it there, security bugs shouldn't be included in this -- they should not initially be public, in following responsible disclosure guidelines; or, if Debian wants security bugs to go through its public bug tracker as well, they should be on the ball and not sit around on these reports for more than 36 hours. So, to wrap up: disclose security bugs you find in a project properly. Contact the project, and if you must post it publicly somewhere before giving the project a reasonable chance to respond, don't sit on it, but contact the project as well and make sure they know about it so they can start fixing it. Do it right, and the one getting the credit for notifying the project won't be Google Alerts; it'll be you. Continue reading "Responsible Disclosure, and Amarok 1.4.10" Saturday, August 9. 2008Amarok File TrackingI don't blog often, but when I do it tends to be meaty. I won't disappoint. I'll be covering Amarok, Amarok history, and a possible future part of kdelibs. "We can rebuild him. We have the technology. Better than before. Better, stronger, faster." A little-known feature in Amarok 1, starting at about 1.4.3, was what was known as Amarok File Tracking, or AFT. For every single file in your collection, on scan, a unique identifier (UID) was generated from some of the file's attributes. If you moved your tracks around your folders, as the incremental scan kicked in, the UID would allow for the file to be identified, and integration throughout Amarok would mean that your statistics, your cached lyrics, and the current playlist would all be updated with the new path. No longer did you have to worry that moving around your files would mean losing years of statistics. Or losing your files. But I'm getting ahead of myself. See, AFT wasn't born AFT. AFT could not track both a file metadata change and a file location change at once, because the UID was being based on file properties such as file length, plus a portion of the file itself hashed together. So you could still lose track of your files. This was a limitation that was known in advance. It was also a limitation that didn't originally exist. As I said, AFT wasn't born AFT. It was born as Advanced Tag Features, or ATF. ATF was the same idea, but a little different -- it would store the generated UID directly in the file's metadata. This allowed for superb file tracking capabilities, because unlike generating a UID from a part of a file, if that part of the file changed, you'd still have your UID. In fact, the only way you couldn't track your file was if you either removed the file's tag entirely (or some other program removed the UID when it shouldn't), or if you removed the corresponding information from Amarok's database. (There are some downsides to this scheme: only certain file types are supported, for instance, determined by the kind of tag they use and the tag's ability to store this kind of information.) So why the change? Well, ATF had a problem, which was related to the structure of Amarok itself, and Amarok's historical penchant for crashing (which got much better as the 1.4 series progressed). The outcome is possibly worthy of an entry in The Daily WTF. In gory detail, here's the problem. 1. Amarok would start a collection scan. The collection scanner was the entity responsible for adding the UIDs to the file metadata. Important note: the collection scan was a separate process. 2. Amarok would crash, leaving the collection scan running, although not communicating with anything. This scanner could be very slow if it was adding the UIDs, depending on whether padding had to be added to the file's tag. If this was the case, the entire file would have to be rewritten. 3. Amarok would be restarted by the user. Another collection scan process would start. Becuase UIDs would already exist for the early files, it would very quickly catch up to the first collection scan process. 4. You now had two collection scan processes generating and writing UIDs at the same time to the same file. If you were lucky, this would mess up your tag. If you were unlucky, this toasted your entire file. 5. Repeat step 4 for the rest of the scan. ATF was never released in this state, but it did get turned on in SVN. And a few unlucky users had far too many files end up corrupted, depending on how crashy things became for them. After we finally realized what the issue was, a user came forward on the mailing list (still trying to find the exact mail or user) proposing a solution that I believe they'd seen in a class. Essentially, the solution relies on modifications to temporary, uniquely named files instead of the original file, using MD5 checksums to find out of the original file has changed while writing the new file, then using filesystem atomicity guarantees to move the new file back over the old one. This became the MetaBundleSaver, and it worked quite well, but it was also extremely slow compared to a normal scan. And most importantly, no one was quite trusting of the whole ATF scheme any more. So, ATF was renamed to AFT and with it came a new algorithm that wouldn't touch anyone's files, but couldn't track as well. A couple weeks ago, I added AFT to Amarok 2's SqlCollection. Enjoy, everyone -- statistics, lyrics, and the playlist are already supported, with support for stored playlists coming eventually. But there's more. Fast forward to today (okay, two days ago). I'm taking a shower -- Wade does insist that there's something about showers and KDE coders -- and I had a thought, which was essentially: there's absolutely no reason why Amarok 2 can't use a UID inside a file, if one exists, for superior tracking, and if not, generate a read-only type for normal tracking. So I created a utility that is built and installed with Amarok 2. It's called amarok_afttagger, and it will write UIDs into your files, using a class ported from MetaBundleSaver and called SafeFileSaver to ensure that files are not overwritten/interleaved, even if you run the process twice or three times at once. It optionally supports recursion if you want to pass in directories, and it can also remove UIDs from your files if you like. Right now it supports MP3s only, but Vorbis and FLAC support will be coming soon. I've tested it extensively. I've added UIDs to files, removed them from files, regenerated the ones in files, over and over, and still everything is cherry. And Amarok 2, when it finds these files, can do some awesomely robust file tracking. I encourage people to give it a run on their MP3s and check it out -- if you're worried by all the Dark Ages info up above and don't have faith in the implemented solution, back up your files first, or operate on a copy of them, until you're satisfied it won't harm your files. And if you still don't want to do it, you can enjoy the less awesome but still awesome power of the non-embedded UID file tracking. Now, I promised this would talk about a possible KDE library. I'll eventually be submitting the SafeFileSaver class for hopeful inclusion into kdelibs, so that any application that is worried about data integrity and needs to write to a user's files can take advantage of it. It's very simple to use -- you simply give it a file path, and then operate on the file path that's returned to you when you call prepareToSave(), instead of the original one. When you're all done, you call doSave() and it will perform the necessary functions. That's it. Hope this has been enjoyable, and enjoy AFT in Amarok 2. Play with it and be amazed. Use amarok_afttagger on your files and be even more amazed. More information is available here: http://amarok.kde.org/wiki/AFT Continue reading "Amarok File Tracking" Wednesday, July 9. 2008Wanted: Portable Media Devices(I'm proxy-posting this for my SoC student, who already posted it on the Amarok blog, so that it gets wider distribution on Planet KDE. Apologies to anyone seeing this twice.) So iPod support should be pretty well set by this next weekend, and the next thing on my list is support for MTP devices. So, what's an MTP device? MTP = Media Transfer Protocol, a protocol Microsoft came up with for media devices. Examples of devices that use it? Pretty much every Creative Zen, iRiver, Samsung and Sandisk media device you can think of, which is why the support for these devices is so important. But I'm at an impasse, since I don't actually have any of these devices. The lack of devices is actually a pretty common issue for the Amarok project, which is where we come to you =). If you have access to a media device which you can donate for development, please let the Amarok team know at: amarok-device-donation@emailgoeshere.com. A list of devices that the project is looking for is available here. This will ensure that the people with these devices are happy people when Amarok 2 rolls around. Of particular urgency to the 2.0 release is the need for an MTP device (see list of MTP devices: here) Any of those devices will be a great help. And, once I have one of those devices in hand and support starts rolling out, I ask anyone who has an MTP device to check out a copy of Amarok 2 from your friendly neighborhood svn server to help me test things out and make support be good (see: here) Lastly, thanks in advance to all of you! Continue reading "Wanted: Portable Media Devices" Thursday, June 26. 2008Popup Dropper -- now with 400% more droppinness!First off -- the PUD now lives in the KDE Subversion repository! It's at svn://anonsvn.kde.org/home/kde/trunk/playground/libs/popupdropper -- it builds with CMake and acts as a standalone library. Included in there is a testapp that you can build with qmake that I use for my testing and that you can use to check it out, which I encourage. Amarok now uses the PUD pulled in as a svn:external, which means Amarok is now very easily synced with updates I make to the PUD. Now, on to the subject line -- the PUD now contains an average of 400% more droppiness. That's because you can now drop on the text of an item instead of just the icon, which means a far larger drop target (and apparently this is how people expected it to behave in the first place). Next on the agenda is to have text change color on hover so you're sure of what you're dropping onto. Complete with a nice looking fade, of course... Continue reading "Popup Dropper -- now with 400% more droppinness!" Wednesday, June 18. 2008Introducing the Popup DropperAbout 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 amarok@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:
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! Continue reading "Introducing the Popup Dropper" Monday, April 28. 2008Amarok SoC: Media Devices + Awesome iPod supportIntroducing 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... Continue reading "Amarok SoC: Media Devices + Awesome iPod support" Friday, April 25. 2008Go Go GTK!Update: Since I've gotten a few relatively profane comments (which I've elected not to post) about blah blah pissing contest blah blah cant we all work together blah blah you are a stupid moron blah blah, please note that nowhere in this post did I mention Qt. This was not a "my widget set is better than your widget set" post. This was a "WTF, why can't I resize this box properly, and why does it end up moving up into the toolbar, how silly of it" post. If it's broken, it's broken, and since I found this to be broken in an amusing way, I thought I'd share it with others. Everyone likes to laugh, after all. So essentially: chill out.
Continue reading "Go Go GTK!" Thursday, October 11. 2007Go Solid Go!I'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:
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. Continue reading "Go Solid Go!" Monday, June 25. 2007The *real* first KHTML browser on WindowsThere's been a lot of hubbub lately about Safari being released on Windows, which is based on WebKit, which is based on KHTML, and how it'll beat Konqueror as the first KHTML-based browser on Windows. Then you hear this other camp firing back about Swift, whose homepage proudly declares "The First KHTML Browser for Windows." However, I'm here to set the record straight. To the best of my knowledge the first KHTML-based browser on Windows is ThunderHawk, which appears to have been using KHTML under-the-hood since at least 2004 and probably at least 2002. Yes, it's a WinCE/Windows Mobile browser. But it's still Windows. Continue reading "The *real* first KHTML browser on Windows" Saturday, May 5. 2007Device Handling and HALMy 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 Continue reading "Device Handling and HAL" Friday, May 5. 2006Bang, bam, boomI'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. Wednesday, May 3. 2006More on the VFAT rewrite
The 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.
Monday, May 1. 2006Karma!
While 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 RewriteATF 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! Monday, April 24. 2006Rip your CDs with KIO and amaroKYesterday 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;
(Page 1 of 2, totaling 16 entries)
» next page
|
Amarok LinksCalendar
QuicksearchArchivesCategoriesSyndicate This BlogBlog Administration |