Bloggy

Since there’s a documentation freeze (and it’s not like I’d, uh, get around to doing a great job updating them anyways. :-( ), I figured the next best thing I could do would be to explain somewhere what the deal is with the cover management code for the JuK release that will be part of KDE 3.5.

First off, a screenshot of one new feature: JuK will try to detect when you’re renaming files that have cover art, and if a folder has the album name, JuK will automatically set the folder icon to the cover art. :-)

Anyways, the new cover management code opens some new possibilities for users. In KDE 3.4, the cover for a track was strictly tied to its artist and album name. Although this proved useful enough, and had a few advantages, it wasn’t a great way to organize the covers. If you wanted to use a cover for a different track, you either had to rename the tags in the track, or you had to duplicate the image. And if your track had no Artist or Album information, JuK would prevent you from setting a cover since it had no information to go by. It worked, but it could be better.

In KDE 3.5, it is better. It’s still not perfect, and I’m not really happy with the Cover Manager dialog window. But it works, and it can save you time while allowing you to do more.

So just as an example, let’s say you wanted to set a cover for tracks you just ripped off of your CD. We’ll use Alabama – Greatest Hits III for the sake of discussion. In KDE 3.3, you could simply select any one of those tracks, and import a cover from the Internet by right-clicking, and using the Cover Manager -> Get Cover From Internet command. As a side effect of the way JuK worked, the cover would be immediately applied to all of the Alabama – Greatest Hits III tracks, whether you wanted that or not.

In KDE 3.4, the procedure is exactly the same, with one exception: You should select all of the tracks you want to apply the cover to first. So you would select all the Alabama – Greatest Hits III tracks before using the Get Cover From Internet command. Or if you only wanted to set cover art to half for some reason, you’d only select half the tracks. Don’t worry about duplicating covers, either: JuK is smart enough to re-use the same image, so you won’t get 14 duplicate .png images cluttering your hard drive.

But what happens if you forgot to select all the tracks you wanted to tag? You could select them and repeat the process, but that would leave a duplicate cover on your hard drive (JuK can’t quickly tell whether two images are identical, maybe I’ll do MD5 hashing later or something). But that’s OK, you can tell JuK to use the cover from another track.

There are two ways of doing this: The first is to open the Cover Manager dialog using the Tagger menu (Tagger -> Cover Manager > Show Cover Manager). The Cover Manager will display a list of all the covers JuK knows about on the right, and after they have loaded you can quickly pare the list down using the search line, or by using the list of Artists on the left. Once you see the cover you want to use, you can drag-and-drop the cover onto a track to apply it. It should happen nearly instantaneously since JuK is reusing the same image (and you’ll see the cover while you’re dragging it as well). Unfortunately, it can take awhile to load the covers, and the Cover Manager isn’t really useful for much else besides.

So this leads to the second method, the one I prefer to use because it’s rather easy. All you do is double-click on the track that has the cover you want in order to start it playing. This will cause its cover to show up in the Now Playing bar, and you can drag-and-drop the cover to the track you want to change exactly as you would for the Cover Manager.

Also note that you can use drag-and-drop to quickly apply covers to more than one track. Just select the tracks you want to apply a cover to, and drag the cover onto one of the selected tracks.

So, that’s about it for my introduction to the new cover management code. If you’re wondering what else it’s good for, here’s some more suggestions:

1. Applying the same cover to tracks with Albums that have (Disc 1), (Disc 2), etc, which you couldn’t do in 2.3 without duplicating the cover.
2. Applying a “generic” cover to tracks if you simply must have a cover on every track, or if you have music that wasn’t released as an album but fits a genre well, you could make yourself a cover for that type of music and apply it to the songs in question.

Posted by mpyne under Uncategorized | No Comments »

Aaron Seigo recently mentioned JuK as an example of why it is useful to have powerful application development frameworks in order to seed great applications.

Aaron said this: “we ship with juk, a great little media player that is playlist centric, kicks ass at tagging and otherwise tries its best to stay out of your way while playing your music. meanwhile, amaroK is an application that is developed by people in our greater development community which is so amazingly killer in its network integration, hardware player support (think: iPod) and general eye candy and usability sweetness that the Ubuntu project actually bent their freeze date rules to allow it into their next release! and instead of fearing for juk’s popularity, everyone (including the juk authors i know) cheer for this success.”

Well that’s certainly my view, and I know that Scott feels the same way too. We will work on JuK to continue to refine it and make it better, but meanwhile we’re just as happy when amaroK continues to improve. And indeed, you’ll find both my name and Scott’s name listed in the amaroK credits thanks to code contributions that the amaroK devs saw fit to use.

In a way, it makes things easier on us. There are many things that amaroK does that simply wouldn’t make sense in JuK. And thanks to the ease of application development with KDE, it’s not unusual for two programs to both have vibrant development teams behind them. I already know the normal argument (why have two applications when you only need one!) but the thing people sometimes don’t realize is that JuK and amaroK are different programs, with different philosophies and intents, which would probably both come out bad from a merger. This is unlike the unfortunate distinct between KEdit and KWrite, which are two programs that should be doing the same thing.

Anyways, on the JuK front, I’ve been trying to fix the low-hanging bugs over the past couple of days, so it’s looking like 3.4.3 will hopefully be the most refined JuK release in awhile. You can see the current set of bugfixes for 3.4.3 at this page.

To potential bug reporters reading this: There are a few crash bugs reported against JuK, which doesn’t horribly surprise me considering the hocus-pocus we perform with pointers. =D But if you encounter a crash, it would be great if you could find a way to reliably reproduce the crash. This helps me even more than a backtrace (although the backtrace would still be appreciated).

In other news, I’ve ported abakus to KDE 4.0 (or the shambles that we’re calling 4.0 ;-), but since the buttons are ginormously tall I think I’ll leave it alone for now. :-/

Posted by mpyne under Uncategorized | No Comments »