Entries by Ian Monroe

We're currently transitioning our blog from s9y to Drupal. For the time being people who blog on s9y itself are blogging there still, but the aggregation is already happening on Drupal so its a good time to change.



Add this feed if you want to follow the blogs of Amarok developers:

http://amarok.kde.org/planet.xml

As a Missourian and a person who thinks Belgium makes some of the best beer in the world, I've been following the story about the possible take over of Anheuser-Busch by Belgium beer-producer InBev with some interest. Personally I kind of want it to go through: it would hopefully mean the end of American beer being judged by its most tasteless examples. There is some good beer produced here. I think people would look at things differently if Bud Light becomes a Belgian beer.



It would also be very ironic and funny, which is mostly why I hope the deal will go through.



The article notes that "The takeover attempt has also run into a political backlash, as Anheuser-Busch, based in St. Louis, is an American icon. Senator Claire McCaskill, Democrat of Missouri, has vowed to stop the deal." Which got me thinking: I would personally find it hilarious if people in Belgium started rallying against this deal due to the damage to their national pride from having their corporations promote products like Bud Light. Any Belgian folks out there feel like writing their MPs?

Our biochemist-in-residence illogic-al just wrote a fun and interesting blog about Amarok on OS X. Interesting because it shows Amarok working on OS X, fun because it shows some of the progression of Amarok 2 in general.

Getting There
Yesterday I arrived in Taipei after about 22 hours of airplanes and airports. At least for a Missouri guy like me, it seems sparling and huge. Fellow Amarok dev and Sydney resident Seb Ruiz isn't so impressed. I didn't get lost on my way to the hostel until the very last block. I walked into a bakery probably looking quite lost (I had been walking around a single block for about 10 minutes) and one of the workers asked me "do you need help?" in English. I showed her the address and phone number of the hostel, she whipped out her mobile and called it, got directions and walked me to the entrance (about 20 meters away actually). So the Taiwanese are very friendly, Seb had a similar experience of someone actually taking him up the elevator directly to the hostel.

The hostel itself (the "Camel's Oasis"), is very homey. I found Seb chatting with a Québécoise about her 6-month world tour (you always find such lucky people at cheap hostels). I did follow Seb's advice and avoided sleeping much on the flight over here (only about 3 hours), but my biological clock still objected to the 11 hour timeshift; I had some pretty spotty sleep last night.

OpenTech Conference
Now we're at Asus for the OpenTech Summit. This morning is being devoted to Asus. Ellis, the product manager for the Asus EeePC (IIRC), presented on how Asus intends to work with the community. A Xandros developer, Brian, went over SDK for the Asus EeePC, which is basically Xandros distributed with Eclipse and Vmplayer. The main development environment they are supporting is Qt 4.2; he did a "Hello World" using Eclipse's Qt Designer integration. Both Ellis and Brian talked about the method for ISVs to release software for the Eee PC; this interests me since it would be really nice to have a way to release the newest Amarok's directly to the EeePC Ass/Remove Programs system. The next version of the EeePC OS is apparently going to make it easy to install .deb's or an EeePC-specific tarball which contains a bunch of .deb files.

I know I promised on-going blogs on the Linux Collaboration Summit, but I failed. From previous experience I knew not to count on reliable Internet access at the conference site; I was planning to just post the blogs I had written during the day when I returned to the hotel. What I didn't count on was the conference rooms would have less electrical outlets then your average dorm room. We blamed the nearby super-computer for taking all our power. The important point is that the battery life on my laptop is about 15 minutes. So I was put in the ironic situation of going to a technology conference, but having access to very little technology. I did have a digital camera though.



From the whole conference there was a real sense of "hey stuff is actually coming together." Not that this will be the year of the Linux Desktop, but that Linux is positioning itself well as the solution for devices that go beyond the desktop. Like the lowcost Asus EeePC is a whole product category that Linux makes possible. The most interesting session on Tuesday was the Mobile roundtable, since there are several competing stacks: Intel has one based on GTK, LiMo has a variation of that, and then Google is building one from scratch (Qtopia was unrepresented). So in the same way you knew IBM was going to win-big with the now current generation of video games consoles (PS3, X-Box 360 and Wii), Linux is going to do well on the smartphone.



The Desktop Architects Meeting was informative, but I hope future meetings will feature more break-out sessions and actual action plans. Kevin mentioned that in DAM-3 they did something like this. The DAM has people from users to distros to upstream desktop developers. We all have a lot to learn from each other, but also different things that need to be worked out. For instance I had hoped for more work with Gnome developers.



An irony is that due to the LCS I'm going to probably going to give OpenSolaris a serious try. Brian Cameron from Gnome and Sun made a compelling case for their set of development tools when we were talking at the IBM reception. Basically it sounds like you can run a tool like Valgrind (dtrace?) that doesn't make the app your debugging run a magnitude slower.



The Firefox representative made a reference to this, he said that OS X is the best tool for Linux development. He was also concerned that Linux distros turn off their system for counting users, which is apparently part of their update system. Well obviously distros are going to want to turn off an update system, I wonder if Firefox even tried having a counting system separate from update? It would be in Linux's interest to have our Firefox's be counted so that Firefox knows how many Linux users there are. I asked him if they would join the growing ranks of Open Source projects with time-based releases, he more or less flatly said no. Of course that's what most of the crowd at aKademy said when Shuttleworth made the same suggestion, and look at us now.



The most useful parts of the Summit were making contacts with people from throughout the industry: some exciting stuff that's probably too early to talk about.

Tomorrow morning I'm headed to Kirksville Regional Airport and then eventually to Texas for the three-day Linux Foundation Collaboration Summit. I've never been to a non-KDE tech conference before; I'm really looking forward to it. There should be lot's of business types, I'm packing a lot of polo shirts instead of the usual Amarok t-shirts I'd wear at aKademy.



Our hotel supposedly has Internet. So stay tuned, blogs are to follow.



Tomorrow is also the cut-off Google Summer of Code applications. For real this time. If you haven't sent in your Amarok application... realistically it's too late since we already have which ones we want in mind. Of course there's always a chance you're application could be better. I just realized the revised GSoC timeline worked out for me, since before I would've been in Texas during the last week of ranking.

Summer of Code is back, earlier then ever. Early is good as it allows some more flexibility in the schedule (students could start on their projects as soon as mid-April, in case they aren't available later), the disadvantage is that I'm probably not the only one somewhat surprised that its starting so soon.



So it's important to get the word out to prospective students. So if you're on any LUG mailing lists or any list with Computer Science students, send them a message about Summer of Code in general and about KDE in particular. Include a link to the SoC homepage, the Timeline and the list of KDE project suggestions*. Offer yourself as kind of the local contact to the open source "world".



I sent out such a email to my local LUG and found a few interested people. The common response was that they had wanted to get involved with open source but weren't sure how, the issue SoC is largely trying to solve. We had a meeting yesterday and it sounds like a couple of students will maybe even develop for Amarok. This is just at a small university... there's a lot of untapped potential out there.



*The suggestion list, at least for Amarok before I cleaned it up, had somewhat degenerated into people putting up feature suggestions (one not feasible, one that was more like a weekend project). Be sure to add project suggestions (for projects you actually know something about), but also double check the other suggestions. Always encourage the students to work with a particular mailing list or IRC channel to help refine the proposal.

Haven't blogged in a bit, so I have a couple unrelated blogs.

Dragon Player 2.0.1

Dragon Player 2.0.1 was released last week. 2.0.0 had a little but very visible bug (pressing the mute button would cause the mute button to disable), but luckly my sense of paranoia of such things kept me from advertising 2.0.0 outside of Dragon Player's website. Credit goes to a few years of Amarok releases going just a bit wrong at the last minute (though this year has been good to us).



Anyways I think Dragon Player 2.0.1 is a solid release. It'll probably be the last release of Dragon Player done independently, as now Dragon Player is a part of KDE Multimedia. We have a bunch of ideas for Dragon Player 2.1 (released with KDE 4.1). Mostly it all comes down to polishing the interface.



About the only difference between 2.0.1 and 2.0-rc1 is the new icon. Which looks utterly fantastic in my opinion. Credit goes to Eugene Trounev of the KDE games project. They have a great community spirit, it's no accident that KDE games was fully ready for KDE 4.

Quassel

While Europeans go to FOSDEM Brussels, drinking their great beer and partying with Mike, us Americanos are stuck looking at pictures and thinking how fun it could have been. Luckly this year something else came out of FOSDEM for us lonely folks: the public release of Quassel. My initial impressions wasn't good: it stalls when you join a channel or connect to a server. But it turns out that the way you use Quassel that doesn't really matter, since the "quasselcore" stays running and you basically never have to join a channel again. So for an alpha, it is very usable and I would recommend it, even if you're only interested in an IRC client and not something to test out. Yesterday morning I added mouse wheel support to Quassel's channel list; it was good to warm my Qt Model/View muscles some. I pretty much had to add it: I would try to use my mouse wheel every time I changed channels even though it never worked.



Some people (apparently everyone but me) experience crashing when they do the initial network setup for Quassel Alpha1. Alpha2 should be out shortly.

Olivier Bédard, our super-cool Amarok network admin, just installed a tool called Fisheye. It's basically exactly what I was asking for in the last post, it lets you easily look at all the recent commits with a nice pretty interface to look at the diffs. There's a little button to send a given commit to the Crucible, where there's a code review system. It is proprietary however.



It needs a local SVN repository, so Olivier rigged up an SVK repo to mirror from KDE. Apparently Fisheye support for Git is forthcoming, which is good since git-svn is the only way to mirror SVN and have it follow Amarok when extragear was reorganized a couple years ago.



You can check it out for Dragon Player and Amarok.

I actually got Review Board running on our Amarok server (only for the local host) just to try it out and see what it was. Turns out I should've just read the documentation first. It clearly states its for reviewing before commits are made, which makes it next to worthless for Amarok development.



Amarok's code review has generally always occurred after a commit. Which is what a SCM is for, if the commit isn't any good you can easily revert. The only exception is for new contributors who submit patches, who probably wouldn't want to register an account on a web app anyways. Currently we use just plain SVN and commit-filter.org to keep track of what each other is doing. The problem with the commit emails is that the diffs are ugly, cut off when too big (eg when a code review is most needed) and don't show new files. Muesli actually made a handy Qt4 web app that showed commits as they were coming in, but it code rotted.



So a Review Board-like software that both accepts patches and lets you look at and comment on SVN commits as they happen would be awesome. So if anyone out there wants to play with one of these new web frameworks (Django, ruby on rails, CakePHP, there's a new one every minute it seems) and make something useful, this would be it.

At work there's a computer with a bad hard drive. There's also a blazing fast Linux server. The easy solution should be to just boot up a livecd that gives the list of local XDMCP servers. Despite this easy demand, I haven't yet found one. I tried Thinstation, it seems to be a bit more powerful then I want. I really don't want to find out and pick which hardware to put on the ISO, that seems so Linux-from-the-90s (though maybe is needed for some really thin clients, I don't know). One of the prebuilt ISO's hangs on loading X.



I was able to use a Ubuntu disc that was laying around, that however loads the desktop before GDM (where the menu option to the XDMCP list is). Too much of a hassle for something that has to be done every time the computer boots. Every LiveCD distro I've every used loads a desktop on boot, instead of KDM or GDM. Someone in #knoppix actually pointed out that Knoppix has a "press a button" easy setup for running a network-boot server. Which is neat, but not at all what I need.



Does anyone know of a livecd that perhaps has a boot time option to load a XDMCP broadcast client? Preferably one of the "just works" livecd's like Kubuntu or Kanotix or something of that sort.

Release Candidate

I just released the Dragon Player release candidate. It really is the release candidate, it works just fine as far as I know. But I'm not foolish, it probably has some problems that only a wider release will discover. The only identified problems so far is that I forgot to bump the version and the README still calls it "Video Player." I used Harald Sitter's Amarok (but very generic) release script, I was able to include i18n in this release for the first time. There's about 20 translations, which surprised me. Thanks to all the translators! I plan on the 2.0 final version to being out soon, certainly before Hardy feature freezes in mid-February.

Solid Magic

One of the nifty additions in this release is that the "Play Disc" button is now smarter then just playing the DVD at /dev/dvd. Using the KDE pillar Solid, it gets a list of all optical media. If there's more then one, it gives the user a little select menu. The main issue this addresses is that some users have more then one DVD drive. Now they can put the DVD in either and Dragon Player will play it. Also there is no longer a need for separate "Play VCD" and "Play DVD" buttons like Codeine had, since Solid identifies the type of disc.



The Solid API takes a little bit to get used to, but it actually makes a lot of sense. You ask Solid for a list of Solid::Device's. Device has a template as() method, that actually returns pretty much any of the other relevant Solid classes. So in my case, I use Solid::OpticalDisc to identify whether its a DVD, audio CD or VCD or just data and then Solid::Block to get the device path (eg /dev/hdc) to give to Phonon.

Gentoo and Xine dev (and part-time "Amarok Helper") Diego wrote an interesting blog about memory usage. Or, at least interesting to folks like me who somewhat regret never having had a operating systems class. He discovered that any Xine client (which includes Dragon Player or any KDE4 app that makes a sound) wastes 1.7mb of RAM thanks to libvorbisenc.



Using his cowstats script, I profiled Dragon Player:

File name                                                       | .data size | .bss size  | .data.rel.* size


src/app/CMakeFiles/dragon.dir/playDialog.o                          0            1            0


src/app/CMakeFiles/dragon.dir/videoWindow.o                         0           17            0


src/app/CMakeFiles/dragon.dir/mainWindow.o                          0           17            0


src/app/CMakeFiles/dragon.dir/actions.o                             0            1            0


src/app/CMakeFiles/dragon.dir/playlistFile.o                        0            1            0


src/app/CMakeFiles/dragon.dir/fullScreenToolBarHandler.o            0            1            0


src/app/CMakeFiles/dragon.dir/stateChange.o                         0            1            0


src/app/CMakeFiles/dragon.dir/theStream.o                           8            9            0


src/app/CMakeFiles/dragon.dir/fullScreenAction.o                    0            1            0


src/app/CMakeFiles/dragon.dir/main.o                                0            8            0

Not too shabby. Also not so important, Dragon Player isn't a library. I just profiled libamarok which is loaded by all the various Amarok plugins so potentially could be an issue. It had 46k copy-on-write sections total, but out of the dozens of files 40k is a variable in the crashhandler, which is a kind of scary piece of code since it has to work while the rest of Amarok is crashing. So I'll let someone else work on that.

Awesome release everyone!



Having KDE4 officially released is making my life easier. Thanks to everyone's favorite MOTU Harald Sitter, Dragon Player is now in gutsy-backports. I've just pointed this out on the Dragon Player website. And Long-time Rokymotioner Enr1x has created an AUR for Dragon Player. So all this makes Dragon Player easy to install, I can't wait for Amarok 2 to reach this point! Dragon Player 2.0 final will then be released in a couple of weeks probably

.

I do plan on working a bit more on subtitle/audio channel issues to make sure it works cleanly. I do feel that I'm spending probably a lot of time on this feature, but I suppose it isn't a surprise given that its one of the few features where I can't just hook up to a Phonon signal and rely on Kretz's code to do all the work for me. And once KDE 4.1 is out, I'll be able to tear most of even this code out.



So as my Dragon Player TODO list has mostly been reduced to testing a couple of things, its time to get back into Amarok 2 code. Hydrogen will be proud of me. I've identified podcasts as really the remaining "why I still have Amarok 1.4 open" issue. Bart has worked a lot with it already, I'll have to see what he has done so far.

As promised, Dragon Player 2.0 beta1 has been released.



Bug reports and feedback appreciated. Especially on the volume slider, I'm not sure I like having the extra toolbar button.



There's a few more items on the TODO list (mainly double checking stuff works) and then a 2.0 final release can be made.



I've also updated the Codeine kde-apps page to reflect the name change. Now to update the Freshmeat entry (not sure people actually still use Freshmeat though, but it can't hurt.)