Author: Tom Chance
Day seven of aKademy here in Ludwigsburg (Stuttgart region), Germany, saw KDE developers finally tackle the tricky question of release schedules and whether they should skip straight to KDE 4 or have an interim release of KDE 3.4. Plans for SVGs in KDE theming were discussed, with some welcome news for those who have been waiting for graphical goodies. And as the name of this section — coding marathon — of the summit implies, keyboards remained busy all day.
Scheduling the morning discussion about KDE release schedules at 10 a.m. gave hackers the discretion of an extra hour to emerge from the Youth Hostel.
A little background is perhaps needed first: A few days before aKademy began, the KDE Project released KDE 3.3, the fourth release in the 3.x series, all of which have been binary compatible (so programs compiled for KDE 3.1 should run OK on KDE 3.3, for example). Major KDE versions (2.x, 3.x, 4.x, etc) tend to follow major releases of the GUI toolkit Qt, and since the first technology preview of Qt 4 was released in July, the KDE Project has begun to look at what it could do with KDE 4, given that it can break binary compatibility, completely rewrite large portions of the code base and introduce radical new features.
If KDE were to jump straight to KDE 4, it would probably take between 12 and 18 months before it came out. If, on the other hand, KDE 3.4 was released in the meantime, KDE users could get a new release within six to nine months.
| Somehow, work got done amid all the spaghetti-like cables. |
Off-the-cuff chats about this subject have been happening through the summit, with distinct differences in opinion already emerging, so the meeting began with a predictable salvo of thoughts. The short release cycle of 3.3 (nine months in between the feature freezes of 3.2 and 3.3, six months in between releases) concerned some who didn’t want it repeated in KDE 3.4; others liked the idea, arguing that it would allow for lots of relatively small changes to add to the polish and stability of KDE 3.3. It would also allow kdelibs to branch as soon as possible to begin working with Qt4, which would let KDE developers notify Trolltech of bugs and shortcomings and to prepare some code sufficiently stable for application development.
Quite how many developers would continue working on the 3.4 release when kdelibs 4 became relatively stable is uncertain — developers present were split — but some kind of consensus began to appear. Though this shouldn’t be taken as a decision of the project, it now looks likely that we will see a release of KDE 3.4, focusing on polish, usability and stability, out within six or nine months. KDE 4 will be some way off, and so those looking forward to a new multimedia architecture, integration with DBUS and HAL, and other major changes discussed in this conference will have some time to wait.
One plan that does seem more concrete came from a short meeting of the KDE Artists attending aKademy. KDE 3.2 saw the first release of KSVG, allowing KDE to use the SVG image format for icons and other elements of the user interface. But in both 3.2 and 3.3, the default icon set — Crystal — was distributed as PNGs, along with all other artwork. Though SVG icon sets are available, KSVG still requires considerable work on the part of the artist and coders to get icon sets to display perfectly. And although more feature-complete than most competing technologies — Konqueror with KSVG can preview icons, for example, and display more of the SVG standard — it isn’t yet ready for a full deployment of SVGs on the desktop.
| Time for a rest after a long coding session. |
But this should change. They hope to have both the artwork and the code ready for all icons to be SVGs, and hopefully wallpapers and other areas of artwork making the change where appropriate too, bringing KDE up to speed with GNOME. By KDE 4, use of SVGs should be mandatory. Work on KDM is also under way, with SuSE sponsoring a KDE hacker to make the theming engine more flexible. All of these changes are being considered as part of a project-wide effort to develop a style guide that will deliver a more consistent look and feel for users and a structure from which artwork efforts within the project can be better organized.
Upstairs in the computer labs, among the small piles of crisp packets and empty bottles, work continues. With all the developers coding and compiling at the same time, the icecream system developers by SuSE is keeping developers happy. Based upon distcc, icecream employs a central server to distribute compilation jobs throughout the network, allocating machines according to how quickly they can complete the job. As well as simply scheduling jobs, icecream gives developers some all-important eye candy to look at if IRC is a little quiet.
The Network Operations Centre (NOC) staff run the show 24 hours a day, maintaining the network, checking in participants and tending to the coffee machine. With volunteers taking it in turns to do night shifts, an airbed and some roll mats provide the all-important crash zone. Keeping a Wireless LAN (WLAN) up for all those attending the conference, as well as several print servers, some webdav filespace and a handful of switches distributed throughout the buildings has happily been administered well.
That the network has remained up is fortunate, because without it I wonder how the developers would survive. For those who are sceptical about the hacker’s IRC habits, I present a small snippet of the aKademy IRC log:
chowells: where are you? almer: in one of the upstairs rooms chowells: lol, which one? “bad bath” apparently almer: chowells: you are sitting next to each other
Finally despite recent rumors, Aaron Seigo has yet to receive a call from Sergey Brin!
