This year’s GUADEC has been really great – it seemed hard to top last year’s but paul, thos, robster and the rest of the GUADEC team really rocked hard to make everything work at its best. Kudos to all of them.
Unfortunately, my GUADEC was cut short on Wednesday for a small medical emergency, as my wife had some health problems on Tuesday night that got worse on Wednesday. Now it seems everything’s back to normal, but as we’re still expecting some of the lab analysis to come through, we had to postpone our holidays and the trip back to Italy.
I could only stay in Birmingham for the GTK+ “state of the union” (awesome) talk by Kris and the 3.x4.x workshop and see the wonderful presentation Fer and Xan did – really funny but also straight to the point. The following discussion was a bit hijacked towards the ABI/API break issue, which I believe is neither interesting nor really important. I also missed the Clutter talk on Thursday, but I was told Matthew rocked. It’s fun to see people picking up Clutter and finding it API-friendly: it’s hard, being very near to it, to judge whether some of the choices you make are the right ones.
I had to cancel my tutorial on Perl and GTK+, as well as the GConf workshop. I’m very sorry if this has caused you some trouble; I heard that Ryan did an interesting talk on his dconf project, though.
I missed Havoc’s keynote on the online desktop, but went to Alex’s keynote; it was intriguing, even though I disagree on some of his points – especially the bit about Firefox being an interesting platform to develop towards or with, after the utter disregard that the Mozilla developers have had in the past for Linux and GTK+ (two issues spring to mind: borked clipboard usage and UTF-8 drag and drop); oh, and I don’t think I’ve ever seen the words “good engineering practises” and “small extensible core” anywhere near “mozilla”, unless “the Fox” that Alex mentioned was a new web browser I’ve yet to see. What I completely agree is that we need to tap into the resources of the non-C, non-hardcore programmers: we need tools to make possible for Flash developers, for Javascript developers, for designers to use our platform, and provide new ideas; in short, make the platform interesting and usable for developers, like the desktop should be interesting and usable for the users.
Let’s take Plasma, the new environment KDE provides for writing their version of desktlets-dash-widgets-dash-applets-dash-somethingets. Obviously, right now, it’s just an exciting new way to write not really useful stuff, like the uptenth variant of a clock, or a weather applet, or a note taking applet; but you get an HTML canvas widget, and you can write ${FOO}ets in Javascript. This way, KDE will get a truckload of useless stuff lying on a desktop which will be covered in windows anyway – but they will also get the attention of web developers writing small apps integrating with web services in a transparent way, using their own strengths and knowledge, without forcing them to learn the intricacies of a complete platform; and in time they’ll get those developers to know this platform and gain new workforce to work with it, and on it. Compare to GNOME: if I want to write something as simple as a desklet, right now, I’d need to know GTK+, Cairo, GConf and possibly gnome-vfs, libsoup, or third party modules for talking to web services through their API. The curve for contributing to the platform is still too steep; and you don’t even get to use your own knowledges: you have to learn everything from scratch. KDE core developers understood this before we did, and their move might keep KDE from falling into the irrelevancy of geek-only usage. It’s up to us find a way for making the GNOME platform interesting again for developers, as well as users.
How about making a freedesktop spec out of plasma and implementing it under gnome. Or better, implement something plasma-compatible in gnome and then create the spec. :) The only problem I see is that some plasmoids probably will use a KDE specific api (phonon, solid, etc) and that would likely fail to work under gnome, but I’m sure something can be done about it.
Another option would be to help out with the Jackfield proyect and make dashboard widgets work on gnome.
just my 2€.
@anonim
starting a discussion on fdo is the first step for killing the baby in the cradle. regardless of that, I don’t want plasma on GNOME – I want something similar, using web technologies. something like the online desktop, but from a developer perspective: the ability to code pieces, extensions of the current desktop using html, flash and javascript.
How can the curve to contribute to KDE be “too steep”? Do you mean C++ with automagic memory management thanks to Qt, or QtRuby, or PyQt, or QtScript are more difficult than hacky C code with manual reference counting, malloc/free, etc? I think you are wrong.
This rant about Plasma makes me remember when KDE adopted DCOP and Gnome people bashed all the time saying CORBA was the way to go. No wonder, Gnome eventually discarded CORBA and adopted DBUS, which is just an evolution of DCOP. I predict the same will happen with Plasma: eventually it will make its way into freedesktop.org, with a few changes and a different name to avoid “political problems” between Gnome and KDE, and Gnome will adopt it.
Edit: I was referring to the curve to contribute to GNOME being to steep, not KDE. And I haven’t been ranting about Plasma: I wrote clearly that Plasma is, in the long run, a beneficial thing for KDE because of its low barrier of entry for web developers; We (in GNOME) should copy this approach. Finally, Plasma being a fdo “standard” doesn’t buy us (GNOME and KDE) anything: it’s too high level to be successfully used outside KDE, it’s not an IPC mechanism or a file format.
The very first thing gnome needs is a simple, usable component framework. KDE makes it relatively straightforward to script an app that includes a browser, which, as you say, goes a long way to integrating lots of online apps, etc. I’d HATE to attempt that in GNOME. Hopefully now that GNOME is using DBUS, it’ll also start using the same kind of components that KDE uses. Then both projects might accelerate each other.