Bloggy

In short: School is boring, but I’m still doing well.

One of my classmates has just recently rigged a tournament bracket for the class (competing with the tests). It’s just like a typical college basketball bracket, except that to advance you have to “cover the spread”, that way those of us who are more intelligent *cough* don’t automatically advance over the other contestant.

There is a flaw to the system though. Our class #1 and I figured out that if he were to place against one of the better Electrical Engineering majors in our class for the quarter finals (which is a EE test), that he would have to score better than perfect to advance due to the way they are currently calculating the spread. By the way, unless regrades go my way, I will have been eliminated from the first round by 0.02 points, thanks again to the spread. ;-)

In other news: I’ve been hanging out with some friends more on the weekends. But more important, my wife has been hanging out with one of my friend’s wives. This is awesome, we’ll get her to have someone on her phone list yet! ;-)

I’ve been spending a lot of time trying to overhaul the kdesvn-build documentation. It’s still not done yet but hopefully it would be much improved by the time I’m done.

One last thing: Jonathan, are you sure they didn’t just remove the logo for a different reason? If it’s true what you claim then I am very disappointed but I think it’s bad form to simply make an accusation when it could be a simple misunderstanding.

Posted by mpyne under Uncategorized | No Comments »

I’m just responding to a few posts I saw on Planet KDE.

First off, a KDE contributor has joined the military (U.S. Army) and was offering his thoughts. Since I have already joined the U. S. Navy I thought I’d offer some (public) advice.

First off, the Voltaire quote he paraphrased wasn’t actually said by Voltaire (although he said something similar in meaning). But it’s “public knowledge” now so don’t fault Aaron for that, I just wanted to clarify. See the Wikipedia entry for more information.

Also, although I suppose it may be different for enlisted members of the military (especially those that aren’t actually in yet), it’s not the best idea to be discussing pretty much anything political on a very public forum. Especially when discussions turn to the current Commander-in-Chief of the Armed Services. Of course, I’m not a lawyer, etc. etc. etc.

I would like to point out to those giving him grief that attacking members of the military does nothing to help your cause. It is the civilian leadership that holds power over little questions such as invading sovereign nations over possibly misleading or trumped-up evidence, or spreading Reserve and National Guard units around the world so that they won’t be available to provide assistance to their home states in times of crisis. I don’t know how it works in other countries but here in America the military is rather strictly under the control of the civilian leadership. This is a good thing, trust me, but this means that your average grunt is as powerless to change military policy as a civilian. The military will exist no matter what anyways, so would you rather have those who are driven by the desire to help and defend their country in the Army, or those who would rather spread destruction across the world?

I also wanted to reply to Tom Chance’s concerns over KDE naming. He says that if KDE adopts a term for applications that are shipped by KDE in addition to the base libraries for development, that 3^rd party developers would also adopt the term and render it useless. But you could apply this reasoning to any of a similar set of situations. I don’t want to go too far into it but it basically implies the kind of malicious intent that is always brought up when discussion sites like Wikipedia but which never seems to actually materialize.

Tom does make a good point that to use a term for KDE’s own applications, there should be a set of guidelines that such apps would have to follow, which would have to be public and have requirements that applications would have to meet. Tom brings this up as if it were an issue, but it’s actually a great idea, and as far as I know we’re already on the way to doing things of this nature. Those who read the kde-core-devel archives will notice that it is becoming harder and harder to say “Hey, I’ve got this great app which I think KDE should ship!”, as more and more is required of applications hoping to make it. I think it would be great to codify what we expect KDE’s applications to support as a minimum base for KDE 4, and either fix apps that aren’t up to spec or boot them out when we do the release.

Also, he’s concerned about the fact that there may be confusion when people say they have a KDE application as to whether they are talking about an application for KDE libraries, or an application by KDE the project. But, Aaron Seigo’s proposal has already taken care of the latter argument. Although I think a better name suggestion is in order, so I’ll throw out a few. First let me note that I don’t want a proposed name to start with a K. Tom already mentioned that if we used Kaleidos as the name, then we could refer to KDE as the Kaleidos Desktop Environment. But it’s not that, it’s just KDE, but why should people think different if we lump our applications under Kaleidos or any other name that begins with a K?

Personally I’d like such a name to be generic as well, and relatively short. Right now I’m leaning towards astronomical names like Terra or Neptune. But I’m not sure if either is used in the computer field. Oh well, I guess it’s good that I don’t get paid to think of names. :)

Note that I’m not unreceptive to Tom’s suggestion that we just leave things alone and pound in the meaning that a KDE application is one built by anyone using KDE libraries. But if this is a confusing issue to people, then Aaron’s idea of naming the kde.org application set makes a lot of sense, and I don’t think it will suffer from the issues that Tom posits.

Posted by mpyne under Uncategorized | 1 Comment »

Seb Ruiz had a question about whether unusable features should be removed from context menus or grayed out.

In his case he is inquiring about the ability to burn CDs from a playlist. It turns out that the feature he’s referring to was actually originally authored by myself as part of JuK. I’m not sure how it’s changed in amaroK since then, but in JuK the feature was always compiled in. It was only disabled if the CD-burning program was not found installed when JuK started. So it would make sense to leave the option there in the menu but disabled.

Turns out that the option is removed if it can’t be run though, in JuK’s case. Or to be more specific, the option is not added if it can’t be run, since the menu in question is constructed dynamically. Maybe I’ll change that someday since I actually like leaving the options there when possible and just disabling it if it can’t be run, if only to keep the menu from changing around.

Posted by mpyne under Uncategorized | No Comments »

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 »