Hi blog, long time no see. What's been happening?
0.8 is out the door. And I've already become annoyed with it. Good thing I'm the only one, people seem to like what we've done.
One thing that ds and I agree on though is that we're going to heavily modify the scheduling in the next big release. (Looks like we'll start that after we got Totem and Rb into Gnome 2.8) The good side: This allows you to wait on file descriptors, pads, the clock or conds in your element all at once and we don't need threads nor cothreads anymore (yay portability!). This will be liked by our video sinks (who will be able to listen to events even when no buffers arrive) or the people thinking about midi (who can send "nothing happened" even though nothing happened on the input). And there's of course the bad side, that rbultje is gonna flame me for: We'll need to rewrite large chunks of our elements. (Of course this has the plus side of finally going into a proper deep inheritance tree and really doing OOP this time.)
Due to ever increasing interest from KDE guys and them not getting a KIO wrapper (that's gnome-vfs for KDE) working, thought "that can't be hard" and deided to write one. Good things: 1) I know KDE a lot better. 2) There is a KIO slave in GStreamer now. Bad things: 1) It doesn't work reliably yet. 2) KDE
Now, before people start doing stuff to me for that second point, let me explain, why I dislike KDE and especially what I dislike. Gnome focusses on the model of separating functionality and using cleanly defined API for integrating all of that. This of course means that you can rip out the parts that you like and use them. You can write an app like the Gimp, that doesn't require libgnome. This doesn't work in KDE. KDE subscribes to the model of integration. In KDE everything is integrated. KIO only works if you have a working KApplication setup in your code. Since a KApplication uses the Qt event loop, KIO uses it, too. And since a Qt app has widgets, you can easily pop up an error dialog via the KIO API. This of course means that you now need X and a full blown widget set on your machine to open a webpage. Even if it's just a command line app. And now try wrapping this in an app that is not KDE.
Luis Ximian made me now write something about the issue I talked about with him last Guadec and that still gets worse: Companies vs Communities.
I still have a bad feeling in my stomach about the GNOME people getting too corporate and starting to a) raise the barrier to entry into the GNOME hacking world, b) hiding decisions from the community and c) steering GNOME into corporate waters far too much. You can see this for example on the Mono vs Java discussion. For a community this is a total non-issue, because a community just uses the tools that it likes to build great apps. Another example is the "we don't include code in Gnome that is possibly patented" (I probably should add "in countries where the corporations backing Gnome are interested in") viewpoint. Communities like Debian found a solution for that problem. Gnome just doesn't ship spring-loaded folders or usable video playback plugins.
But the most important thing for me is that the people I interact with are more and more employees that need to get a job done, not people that hack on their project for fun. (Add the bounties here if you want.) IRC nicks end with @redhat.com or similar instead of .edu, .pl or .net. And this is especially bad because the newbie help is missing. Because helping newbies offers no short-term benefits and people nowadays need to get a job done. But that reduces new blood coming into the GNOME world. And I believe that without new people joining, GNOME will not be able to scale. GNOME needs all those testing volunteers that run broken cvs builds and report bugs, categorize the bugs, do translations, create new artwork, provide patches or write new tools. You'd need to throw a lot of money in that direction if you wanted to pay for that. And it is my strong believe that you can only attract people to your cause, if you provide a community to attract the people. If someone is interested in GNOME but doesn't know how to get involved, joins #gnome and speaks a shy "hi" and then noone answers, GNOME might have just lost a valuable contributor. I still know this day three years ago when I first joined #gstreamer and said a shy "hi" and people did talk to me. I liked it more than the other places I tried, so I stayed.
You can say that in business terms, too: If noone had taken the 15 minutes to convince me to stay, Gnome would not have gotten contributions for free that would probably have cost a 6-digit Dollar-amount to get professionally.
- Who are ebf and riggwelter? It's certainly funny when people show up certifying you at Advogato that you don't know and can't even classify.
- Valgrind rocks. Not just using it, but adapting code for it, too. The header contain great documentation. Noticed that when adding support for it to GStreamer. It's slow though. Really slow.
- Squashing memleaks like mad. Loading 1500 files into Rhythmbox only takes up 50MB instead of 500+ like before. Need to make teuf pound on it a bit more.
- Rhythmbox plays mods. Yay. And if someone released GStreamer 0.8.1 I could start working on making it release the sound device on pause, which 0.8.2 will support.
- hadess: Since you wanted opinions about USound, here's mine: Let them deliver first. There's a lot of sound servers that don't work already. Oh, and they should definitely write a plugin for what I the future sound API: alsalib.
- Miguel is a Troll. Had to be said. Thx to tberman for listening to my rant on IRC so I didn't feel the need to put it somewhere permanent.
- Anyone have an idea how much voodoo-fu it'd take to make this use a GStreamer backend?