May 31st 2006
Today I finally qualified as Engineering Officer of the Watch. This is awesome if only because I’ll be spending a lot less time at Prototype. Graduation won’t happen any quicker though, it’s still at the end of June timeframe.
May 19th 2006
I finally passed Final Watch Board. You may remember me talking about getting psyched up for it 5 weeks ago… and then a week ago, and then the boat broke. :-(
They got the boat working for long enough to start training again, and they squeezed my Final Watch Board in at very little notice to myself. Kind of a “Oh, by the way, come in tomorrow at 8:30 for your board. Sorry about you losing the day off.”
Apparently I did alright. 3.07/4.00 was the final grade (2.50 is passing). So far I believe that’s the highest grade among my crew. I got two casualties that I hadn’t prepared for. One I hadn’t prepared for because it was so easy, the other I hadn’t prepared for because of several reasons: It’s very hard, I had a similar casualty earlier (they normally give you casualties you haven’t had), and the staff had been pushing other hard casualties as things to study for. Luckily I wasn’t just completely unprepared, but it was going wonky at times. :)
Now I have about 40 more checkouts to get and I can go to Final Oral Board and qualify. :)
May 12th 2006
Sweet, the flamewar has started. :) Christian Schaller, gstreamer-developer extraordinaire has mentioned that he thinks Phonon is a bad idea for KDE. (For those not in the know, Phonon will be a multimedia layer for KDE 4 designed to be independant of the actual audio playing code).
When I saw this, and the reaction that erupted on the Internet, I have to say that I’m very disappointed. Aaron Seigo has already made a good reply. So has Scott Wheeler (JuK’s author). But I still want to add my two cents.
Essentially Phonon’s sole purpose in life is to make it easy for KDE applications to use multimedia, without binding KDE applications to a specific backend. In other words, Phonon doesn’t actually play audio or video, it simply acts as a wrapper around code that does. Code like gstreamer.
Now Christian claims that Phonon will either have to be so high level that no application will be able to use it, or so low level that it is simply a KDE-invented multimedia framework. In other words, Phonon will either be useless, or it will be aRts. The solution to this issue? Just standardize on gstreamer, of course.
Now the reason I’m disappointed: This is so untrue that it’s scary. I can think of quite a few KDE applications that need to be able to do nothing more than play a sound. Kaboodle. KNotify. Half of kdeedu. And this little application I work on called JuK.
Let’s talk about JuK and gstreamer. When gstreamer 0.10 was released, it broke compatibility with gstreamer 0.8. So if any JuK users upgraded gstreamer and removed 0.8, now JuK wouldn’t work. (Yes, I have had bug reports like that). Well, that’s cool. It’s easy enough to add support for 0.10, right?
Well, I think the jury is actually still out. We added 0.10 support successfully (and even removed support for 0.8 in /trunk). But I came across a bug I wasn’t able to fix. I suspect it was due to the fact that gstreamer 0.10’s changes to the event loop meant that we had to do something special in JuK since we are using the Qt event loop. I even asked the gstreamer mailing list. Turns out I did get a response after a couple of days (thanks Wim!), seems the reason is that gstreamer no longer works the same as it used to with the synchronous interface. Fair enough, Wim is right when he says users will appreciate an asynchronous interface. But if this is the kind of work I have to expect when 0.12 comes out, then sign me up for Phonon. :P I mean, JuK does nothing more sophisticated than playing, pausing, and stopping a song. So imagine how hard it would be for e.g. the amarok guys to port from 0.8 to 0.10.
So, what we should be expected to do then? To “standardize” on gst-0.10 and never be able to upgrade due to binary compatibility requirements? Wouldn’t that be ironic… 3 years from now people would be accusing us of forking gstreamer 0.10 after the rest of the world was able to move onto the new hotness, gstreamer 0.12. Of course, we couldn’t move because we had to maintain binary compatibility with software that was no longer maintained, and which no KDE developer was familiar with. Sound familiar?
Or to put it another way, how long will the gstreamer developers guarantee that they will work on whatever gstreamer branch we would standardize on? Either they will develop a new branch and freeze the branch we use for only bugfixes, and thus stop our feature development, or they will continue to add features to the same branch for something on the order of five years. Because that is the very freaking point of Phonon: To be able to allow KDE users to upgrade to kdelibs 4.3 with support for the latest multimedia libraries, while the KDE applications compiled against 4.1 will still work. In other words, we are tired of multimedia libraries, and are divesting that kind of crap to layers like gstreamer. Of course, once it’s possible to move to gstreamer’s next version, it’s not that hard to design a simple layer around other multimedia frameworks. (e.g. aKode, NMM, etc.)
On that note, I still wonder why it’s so hard to maintain binary compatibility when you’re using a C library. It’s doable with C++, and that’s like 10 times harder than doing it with C. ;)
The reason this hurts is because I see all the comments on the people’s blog, accusing us of NIH (Not Invented Here syndrome). And if there is any kind of ironic, bullshit kind of response I like to see, it’s GNOME users accusing KDE of NIH. Forget the fact that aRts has required glib since like arts 1.2. Forget the fact that we’ve supported HAL and D-BUS since KDE 3.4. KDE is only ripping out DCOP and replacing it with D-BUS for KDE 4. I certainly still don’t see any Qt-using code in GNOME or GTK+. And I’ve been railing against people whining about glib on KDE lists for years now, only to get to see this whole flamewar when I get back from work this morning.
So, once and for all, let’s get some requirements and basic facts straight:
I’d love to take up the banner for you Christian, but the plain and simple fact is that we cannot depend on any specific branch of gstreamer. We can’t even depend on gstreamer-ish things (i.e. a Qt wrapper API), because if it’s too tied to a branch it will be useless when the next gstreamer major release comes out. We tried this once for gst-0.6 and it came back to bite us in the ass. It took forever to get gstreamer 0.8 support in JuK due to that.
You mention that GStreamer has always championed the GNOME and KDE should have a common multimedia framework. I agree, but now I tell you this: It will only be possible with Phonon, at least at this point. I mean, yeah, Phonon does stuff other than simply wrap multimedia. But that’s all besides the point, we need something like Phonon even if we were to do nothing more than track gstreamer releases. This is especially true regarding the point that you guys seem to be focusing on, the “what if gstreamer goes away problem”. Yes, I am quite sure that gstreamer will be maintained for the next 5 years. That’s not the issue. The issue is if the same binary compatible release series will be maintained (and not just bug fixes, all the features too, we don’t want some shitty second-rate crap). I don’t believe you guys will do it. And why should you, as it would involve tying your release schedule to KDE’s. That would be stupid.
And finally, it would be nice if, in your criticisms of KDE code that you don’t misidentify what the code is trying to do. Judging by your comments you seem to be under the impression that Phonon would be used against a few different backends simultaneously (i.e. support the best of all worlds). This is certainly not the case. I’m not sure about the exact technical details but I would be surprised if Phonon supported more than one backend per desktop session, let alone per application. So if application developers wanted to require gstreamer, hey, that’s cool, but at least JuK will still work no matter what MM framework the user has.
And that’s not counting the comments left by various users, many of whom I suspect have never opened a code editor in their life. One user said this: “it [Phonon] wants to be an abstraction to provide a uniform API to provide multimedia capabilities, except in the process it is making everything but the most simple of tasks more complex.” But, it is doing nothing of the sort. It is making the easy things easier, and it gives up on the harder things. :-P Another user suggested that instead of writing a 5000 line interface and be done, we should instead be working on helping to maintain all those thousands of lines of glib code that comprise gstreamer. Uh, no thanks, we’ll let Christian, Wim, et al. handle it thank you very much. One users asks why KDE doesn’t just add gstreamer backends (and proves he’s missing the point…). I guess he’s never heard about gst-spc, which Chris Lee and myself have worked on. Really makes someone feel good, to see so much FUD against the desktop environment you’ve been slaving away on for years…
So to conclude, just let me know when you guys are ready to enforce binary compatibility in the release series that you are actively developing for KDE 4’s development lifetime, and I will let you know when it’s a good idea to dump Phonon. :-P
May 8th 2006
So today I released a new version of Abakus (the simple useful KDE calculator). Basically we show the more important part of long answers by default, and abakus supports using the correct decimal separator according to the KDE locale settings.
A couple of months ago I tried porting Abakus to Qt 4, which actually sort of worked, but I don’t think it looked too nice (something about the layouts being wrong). I’ll have to try again soon, which brings me to my next question: Should I push to get abakus included by default with KDE 4? I know that Jonathan Riddell mentioned it way back when. And even now it seems to be one of the more popular applications I’ve been responsible for. (In fact, the reason I made a release today is because someone emailed saying they love the application, could I add this feature? Whoops, the feature has been in SVN for months now, maybe I should release it…)
Of course then the issue becomes what to do with kcalc? I mean, I suppose I could add a button bar to abakus (like what Johan has done with SpeedCrunch), but it just seems… wrong. But then we don’t want to have two programs doing the same thing either. Hmm. Maybe I should ask the guys at OpenUsability. :)
Anyways, I haven’t blogged in awhile. Last time I mentioned how I was psyching myself up for my Final Watch Board. Well, it got delayed because of the poor performance of the officer who went the day before I did. The upper management freaked out and postponed the Final Watch Boards for myself and the other officer who was supposed to go that day. It was pushed back to 12-May in my case. But guess what, now the boat is broken, and unless they get it fixed fast enough (not likely), they’ll have to postpone my Final Watch Board *again*. :-(
And without the Final Watch Board, I can’t take the Final Oral Board and qualify. argh.