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.
5 Replies to “GUADEC/recap”
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â‚¬.
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.
Comments are closed.