Feed aggregator

Free t-shirts were popular

Tonight the Gran Canaria Desktop Summit was opened with a party sponsored by Kubuntu's very own Canonical. Stickers, t-shirts and beer were all given out to contributors and users of KDE, Gnome and any other free software environment. Some converts were made from the local Canary island population who were enthused by the spirit of freedom.

Heavy metal and free software do mix

Conversation ranged from the essential cross desktop collaboration issues to the question of whether it ever rains in Las Palmas.

More photos on Flickr.

read more

Each release of Plasma over the 18 months since its debut release has marked an impressive step forward in its evolution. We are planning on making 4.4, our second anniversary release coming in January 2010, more of the same in that regard.

We recently had our Plasma release cycle planning meeting, and here is our list of goals for central Plasma technologies in 4.4 (in no particular order):

• Improve kiosk based lock down and deployment management: We are communicating with some large deployments in Europe about the process of migrating from KDE 3 to KDE 4 and how we can make KDE 4's desktop shell an even better experience than Kicker and KDesktop provided. We've started a wiki page here that we are working on with these downstream users. Expect a lot more to find its way there over the next few weeks and months as we continue to work out the needs and use cases with them.



• More Cowbell JavaScript: A full JavaScript AppletScriptEngine that provides access to all of Qt and KDE core libs and JavaScript DataEngines.



• Plasma Netbook: A Plasma shell optimized for the netbook use case of a small-ish screen, hardware accelerated video and online usage. It features no taskbar (relying on the "display windows" desktop effect instead), an integrated panel and window title bar, Plasma widgets and a full screen search and launch interface. Hopefully we'll be able to add a media interface as well.



• Media Center Components: A first release of media center components for browsing, collecting and playing media in a full screen Plasma containment. This will not replace Amarok, Dragon, Kaffeine, etc. It's designed for casual full screen usage and will also sport Plasma widget support. Oooh! Full screen widgets! :) Essentially, we believe that a basic media center experience should be easy for the home user to get at, which means it needs to be integrated with the desktop shell and be readily available with it. As a first release, it won't have tons of bells and whistles (something we hope to eventually get by integrating this work with existing media center projects in the future) but it should get us on the right road.



• Remote Plasma: Send your data or your widgets to another computer or device or receive Plasma components on your device. No-configuration local area announcement of services over UPnP, working with all Plasma components without modification, integrated authentication and access control and extensible delivery mechanisms will allow us to share components around a table (e.g. at a meeting), control other systems (e.g. a media center) in the house or even run Plasma services on headless systems on the network. No other widget system out there has this, and even the web hasn't yet achieved this level of relocatability.



• Pluggable Containment Actions: Want to have Control+Alt+MiddleClick open up a list of running windows? Scroll wheel on a panel skip through desktops? This plugin based system for defining contextual actions for containments opens up all those possibilities as well as the more mundane but much wanted consistency between containments. Now Folder View Activities can have all the same options as the default Desktop Activity without any duplication of code. Best of all: you get the final say by selecting the plugins and the activation sequence for them if you wish in the integrated control panel.



• Widget Explorer: A more "Plasma" widget explorer that integrates better with the panel controller, looks hotter and is generally just more usable.



• Improved KWin Integration: We've been working on this in 4.3, and we'll try and take it to new levels with the KWin developers. This includes moving some of the effect inside of Plasma into KWin for greater performance, taking better advantage of some of KWin's effects and seeing more Plasma based theming options for KWin (such as window decorations). A good portion of this work will be done by the KWin developers, but I figure it makes sense on this list as well. :)



• Social Desktop and Geolocation Improvements: Building on our start with the Social Desktop features in Plasma in KDE 4.3, we will be adding more features to the existing widgets, adding new widgets where needed and using geolocation in more of our components. We are also looking at ways to improve the geolocation DataEngine itself, though no concrete for 4.4 plans have been committed to yet.



• Plasmate: The 0.1 release of the Plasmoid and DataEngine creator will follow with the KDE 4.4 release. Transparent revision control, live previews and minimal-clicks-to-get-to-work workflow will lower the bar considerably to making scripted Plasma components.



• KUIServer Resurection: KUIServer has received a facelift and an internal resurrection. Now jobs can talk to KUIServer and it updates Plasma for its job notifications. This means applications like Dolphin can now also consume that data without Plasma getting in they way and if Plasma should crash the jobs will still be there on restart.



• Notification Improvements: Notification summaries, queueing and logging, making the notifications area more robust against applications flooding it and more useful by keeping the latest information at your fingertips. We're also exploring the best way to show only the new stuff when it arrives, while letting you click through to the older stuff, too.



• Kinetic: Plasma in KDE 4.4 will be the first release to start using the new Qt animation and state machine framework.



• Plasma Desktop D-Bus Access: A full D-Bus service exposing the widgets, containments and more in your currently running Plasma desktop session.



• More KRunner: In 4.3 KRunner received a lot of interface, performance and stability love. Now we need to keep the runners coming. I started a Kopete chat runner the other day based on a request received on identi.ca.



• Plasmoid Updates: Working with the KNewStuff developers, we want to provide an easy way to check for updates to the Plasmoids you installed over the network as well as check the installed ones for integrity.



• Notification Item Goes Prime Time: With the new D-Bus based system tray protocol in place and under real-world usage in 4.3, we will be porting as many apps as we can get our hands on to it. A formal specification is being written which will be submitted for consideration at freedesktop.org and we hope to move the KNotificationItem class into libkdeui. Next to the ability to put Plasmoids in the system tray (and possibly elsewhere like the quick launcher), this is the single most exciting thing that's happened to the system tray since I've been following KDE. Finally we have a modern system tray / notification area with the ability to have multiple views on the same entries, have non-graphical representations of them, separate the entries into different groups in different widgets, integrate them with the taskbar, react to the internal state of the entries (e.g. for autohide) and theme them properly for the host desktop shell (icon theming, sizing, etc).



• Improved Documentation: Work on extended JavaScript Plasmoid tutorials is underway, and we're growing the general body of documentation around Plasma.



• New Configuration Dialogs: A revamp of the existing activity and wallpaper configuration as well as Plasma global settings is planned. Beauty and usability are the goals.

That probably seems like a lot, but most of the above items have already had significant work done on them and are currently in active development. We do have more plans, such as improving the Lion Mail Plasmoid and working on improved Akonadi integration, but the above sums up the big changes coming to the core components. The usual incremental improvements in other Plasmoids, performance and stability work can also be expected. (They just make crappy line items in a "OMG! What colour poniez are they making?!" list.)

There's so much more that's possible, too: a dock PanelContainment, improved pager usability, getting kdewebkit to a place that we can replace our use of QWebPage with KWebPage for Plasma::WebContent, a Plasmoid based on the Kickoff internals that shows a menu of just a certain sub-menu in the application menu hierarchy, .... there's lots of cool stuff just waiting for eager hands.

Maybe those hands belong to you? If so, come find us on irc.freenode.net in #plasma or on the plasma-devel at kde dot org mailing list. Either way, enjoy riding KDE 4.3 while we work away on KDE 4.4. :)

Hello planet!

I have just committed a game to playground in pre-pre-pre-alpha stage called Rubots.

The game us written in Ruby (qt-ruby so far, needs help for kde-ruby) and uses Player/Gazebo as backend.

What I am talking about? What is this software?

Gazebo
Gazebo is a robotics simulator. A .world file is created where one can introduce models (everything written in XML, not very nice but usable). This defines the 3D world of the simulation. Gazebo is done in C++ and provides an API to control de robots' actuators and read their sensors.
It also have a plugin for Player.

Player
Is a robotics middleware. One of many. The idea is create an abstraction with interfaces. For instance Position2d interface has commands to set the speed and the position of the robot. One dont really care about what is the actual architecture of the robot (how many wheels, where is the driving train), this is done by low level drivers.
This software is used to control REAL robots, is popular and has Ruby bindings.

When used together, Gazebo via its plug-in cheat Player and make it believe it is controlling a real robot when in fact it is controlling a robot inside the simulation.

So this is the idea:

Gazebo simulating a couple of robots in a battleground scenario
Player controlling and passing data around thanks to ruby bindings and Gazebo plugin
Ruby programmed robots to actually move the robots around and fight!

Think of this as Robocode in 3D and programed in Ruby.

Benefits:
- For Player/Gazebo : lot of testing. I have already found deficiencies and solve them in that software thanks to the stress of the game.
- For Ruby: The game tries not to cheat if possible, meaning the robots programmed for the game will work as it in real hardware!
- For KDE: Get a neat new game :D There are any serious KDE application done in Ruby?

Currently most code is kept in two files as it is easier to develop like this, it will eventually break into files

I have set up a site for planning.

Help and comments are very very much welcomed.

Since yesterday a lot things improved.

In this example I killed all but one rabbit after 1200 rounds and all but one wolve after 7700 (of 10000) rounds:



Quickpost this image to Myspace, Digg, Facebook, and others!

I spent the afternoon working with some very small computers that we picked up today from a local shop that specializes in electronic parts for things like hobby robotics:



The white breadboard in the picture is 4.3 centimeters along the wider side. One day in the not-too-distant future a Plasmoid will live on the above device and I will be able to access it using Bluetooth and then control the device from my Plasma desktop.

Rob L. and I put some more work into the wire protocol and looked further into what will be needed to integrate it with Rob Scheepmaker's remote Plasma work. Rob L. wrote some code for the device and we got a couple steps further.

I have no idea if this idea will ever see the light of day in a commercial product, but I also don't really care to be honest. It's a fun hack that I'm spending some of my free time on and it stretches Plasma out to a whole new area. Wheeee for having fun. :)

A long time, I haven’t written about Kolf. I’m not having any time for coding lately, but Zeng Huan, our GSoC student, has made progress on the automatic generation of terrain textures. The code for that is not in Kolf at the moment, we have decided on him working on it in a separate test bed, the kolf-textureblender:

In other news (which might be more interesting for most readers at the moment), Kolf in KDE 4.3 is broken. The first hole of every course loads fine, but on the following holes, only one object will be displayed (which is definitely too less). Mauricio Piacentini looked into the code, but didn’t find anything. He meant it looks like Kolf is trying to re-use objects from previous holes, but some changes in Qt 4.5 seem to interfere with this technique very badly. If no one finds the bug quickly (which will likely not happen, as the code of Kolf 1 is a total mess), it is quite realistic that we will have to remove Kolf from KDE 4.3.

If this bothers you and you want to help Kolf return in KDE 4.4 as Kolf 2, please join our team! Write to the kde-games-devel mailing list for more information.

Posted in Kolf

I just released lekhonee v0.6 . Download the source.

For RPM(s) , download from koji.

New features and fixes:

• Preview option fixed in the KDE based frontend, old menu based options removed
• Editing option for the last 10 blog posts. Users please tell me if you need to get more
• Insert Link error in the gnome frontend is fixed
• Add categories is also working under gnome frontend (forgot to write code in the last release)
• “Save Draft” option on the gnome frontend is also working (Again forgot to write the code)

If you want to go back from the “Old Posts” list in the gnome frontend , just select anything the list and press “Escape”, in KDE one, there is a button on top to handle this.

To edit the entries you have to double click on the post title.

The post is brought to you by lekhonee v0.6

Dear all digiKam fans and users!

Kipi-plugins 0.4.0 maintenance release for KDE4 is out.

kipi-plugins 0.4.0 tarball can be downloaded from SourceForge at this url

Kipi-plugins will be also available for Windows. Precompiled packages can be donwloaded with KDE-Windows installer. See KDE-Windows project for details.

read more

Disclaimer: as said below, I never used GIT for development, so the characteristics that I attribute to it are based on what I have heard about it from other developers…

I personally have been and still am a supporter of SVN, and of the fact that (as some friends noticed) it’s not so cool having to download, with GIT, the whole project history just for trying some new features in trunk/ (but maybe there is an option to avoid it, I don’t remember exactly…); as of today, I have only used SVN for my projects (GIT and CVS only for downloading some bleeding edge software), and I also have a local repository with that VCS.

But, in the last weekend I started to rethink this fact: developing my GSoC project, I often had the necessity to create a local branch on the fly, sometimes because, in the middle of the development of a new feature, I or someone else found some serious bug, which should be solved asap and its new code uploaded in the remote repository, sometimes because there were more than one way for solving some problems, and it would be nice to try them in parallel, sometimes because you just want to revert only a part of the last modifications, but the revert option erases everything…

I admit that having a good IDE, with a good history of last modifications, may help in this way (and Eclipse, my usual IDE, does help), but it looks like that, in the end, a distributed VCS does make the difference, so I may start to try GIT for real, and then I’ll tell you if it is worth develop with it…

Claudia tells me I should use microblogging. I don’t know. Maybe I can write 140-character paragraphs instead. Is that ok?
The Canary islands are beautiful and rugged. I will leave it to Jos to wax lyrical about them. I have been hiding out in the ops room, compiling.
There will be Solaris Nevada b.115 packages for KDE4 out in a few hours. Then I can demonstrate the same on Sun Ray — and how ugly it is.
No one has exploded from stress *yet*. But then, the first real event of the day is about 25 minutes away.

Wow! The last few days have been eventful. Only four Days after LinuxTag and the KDE Wiki Meeting I am sitting in the check-in area of the Berlin-Tegel Airport heading for Madrid. If everything works out as expected, I will then transfer to a flight to Las Palmas. I swore myself not to blog before I have checked in successfully, so the time for this entry is now, and to make it even more obvious:



The weather is awesome in Berlin already so I am looking forward how Gran Canaria will beat this (probably less thunderstorms in the evening, although they are really refreshing).

At GDCS, I will present Qt Creator, the scalable C++ IDE from Qt Software (I even brought the leaflets I printed LinuxTag, my bag I short of over baggage). I am looking forward to meet everyone again tonight at the welcome party!

Dear all digiKam fans and users!

Utimate digiKam 0.9.6 release for KDE3 is out. It's a bug fix and translations updates.

digiKam 0.9.6 tarball can be downloaded from SourceForge at this url

No more KDE3 release is planed in the future...

Coming back to Oslo (from LinuxTag in Berlin), apparently the heat wave which hits Europe was its peak, at least here in Oslo. To add insult to the injury, it does not really help if the ventilation system acts strangely, which it usually does right when you need it. We sort of enjoy the rare moment when Oslo is warmer than most other places.

In any case, Berlin was fantastic. There were already few blog posts (e.g. from Lydia, Chani, Sebas, Frederik) about LinuxTag so I won't write too much about it. I was very content with my talk since the room was quite filled when I was doing my presentation. The Qt booth was fun as well, I managed to have short chats here and there with the fellow Berlin trolls, KDAB guys, KDE people, and some other new contacts.

As it was nicely planned long time ago (except a little glitch with some kind of a desktop suite program :-), we did manage a cuisine-exchange program (and it was not about pizza). Hmm, I still need to find those pictures...

Just like last year, this fall we will have another Qt Developer Days. Europeans might want to visit Munich, Americans are better served with San Francisco.

Will I go there? Well, unless there is something wrong, yes I will. Note that a little information about the sessions is already available. I leave it as an exercise to the reader, which talks in the Innovate track I will hold :)

Since three brings the luck and it is the first Mersenne prime, I am glad to list three QWebView tricks for your pleasure:

Night-mode

Snap scrolling:

Transparency, something you have also seen before:

As others on PlanetKDE already wrote we had a really great time in Berlin last week. The KDE/Kubuntu/Amarok booth was well staffed with my favorite gearheads and new KDE people now to be added to the former group It was nice to meet you folks! One of the best things about this year’s Linuxtag: We finally managed to get our booths (KDE, Kubuntu, Amarok, QtSoftware and KDAB) together as close as possible No more running from one side of the exhibition to the other like in previous years \o/

Thursday was probably the busiest day for me. Ingo interviewed me about Amarok for RadioTux. (Excellent job as always, Ingo! ) The recording of it is available at RadioTux. Shortly after that I had to rush off to join Alexandra in giving an introduction to community management in free software projects in our “Community Management 101″ workshop that was well received.

The other days were filled with meetings and lots of talking to visitors and other projects. It is nice to see the shift in attitude towards KDE 4 compared to Linuxtag last year. A lot of people came to our booth to let us know they use and like KDE 4 now. This really rocks! Those who were not happy with KDE 4 yet mostly had very minor problems which we fixed in a few minutes; like showing them how to add applets to their taskbar or what the places bar in Dolphin is capable of. Oh and I was surprised how many people first didn’t believe I was running a stock KDE 4.2.4 on Kubuntu on my 7′ EeePC. So once again: The tiny thing does indeed run KDE 4 Special thanks for that to the Plasma and KWin team. Plasma and KWin on the EeePC are quite an eye catcher at events like Linuxtag.

Kreuzberg surprised a small group of us on Saturday with CSD. Definitely not what I would have expected for that evening but it was awesome! And let me tell you: Marge’s outfit was great but it wasn’t the best one by far. That one goes to someone dressed as Hellboy shouting “KDE! Awesome!” after seeing Frederik’s KDE shirt. This was my second time in Kreuzberg and the second time there was a party on the streets. Rock! (Way less police than on May 1st though )

Sunday and Monday Frank, Cornelius, Thorsten, Danimo, Dominik, Milian and I met at the QtSoftware office to talk about the future of KDE’s wikis. It was quite productive and results will be visible soon.

Thanks go to KDE e.V. and Amarok for funding and of course the Linuxtag team for another great event.

Oh and btw: I of course signed the FLA as well. (I think I got number 10 - nice round number.)

Everyone going to Gran Canaria: Have a nice time and lots of fun and make sure to blog/dent/tweet a lot for those left behind at home. I want to see lots of photos

As others on PlanetKDE already wrote we had a really great time in Berlin last week. The KDE/Kubuntu/Amarok booth was well staffed with my favorite gearheads and new KDE people now to be added to the former group It was nice to meet you folks! One of the best things about this year’s Linuxtag: We finally managed to get our booths (KDE, Kubuntu, Amarok, QtSoftware and KDAB) together as close as possible No more running from one side of the exhibition to the other like in previous years \o/

Thursday was probably the busiest day for me. Ingo interviewed me about Amarok for RadioTux. (Excellent job as always, Ingo! ;-)) The recording of it is available at RadioTux. Shortly after that I had to rush off to join Alexandra in giving an introduction to community management in free software projects in our “Community Management 101″ workshop that was well received.
The other days were filled with meetings and lots of talking to visitors and other projects. It is nice to see the shift in attitude towards KDE 4 compared to Linuxtag last year. A lot of people came to our booth to let us know they use and like KDE 4 now. This really rocks! Those who were not happy with KDE 4 yet mostly had very minor problems which we fixed in a few minutes; like showing them how to add applets to their taskbar or what the places bar in Dolphin is capable of. Oh and I was surprised how many people first didn’t believe I was running a stock KDE 4.2.4 on Kubuntu on my 7′ EeePC. So once again: The tiny thing does indeed run KDE 4 Special thanks for that to the Plasma and KWin team. Plasma and KWin on the EeePC are quite an eye catcher at events like Linuxtag.

Kreuzberg surprised a small group of us on Saturday with CSD. Definitely not what I would have expected for that evening but it was awesome! And let me tell you: Marge’s outfit was great but it wasn’t the best one by far. That one goes to someone dressed as Hellboy shouting “KDE! Awesome!” after seeing Frederik’s KDE shirt. This was my second time in Kreuzberg and the second time there was a party on the streets. Rock! (Way less police than on May 1st though ;-))
Sunday and Monday Frank, Cornelius, Thorsten, Danimo, Dominik, Milian and I met at the QtSoftware office to talk about the future of KDE’s wikis. It was quite productive and results will be visible soon.

Thanks go to KDE e.V. and Amarok for funding and of course the Linuxtag team for another great event.

Oh and btw: I of course signed the FLA as well. (I think I got number 10 - nice round number.)

Everyone going to Gran Canaria: Have a nice time and lots of fun and make sure to blog/dent/tweet a lot for those left behind at home. I want to see lots of photos

I haven't blogged in a while...generally it's because I prefer to blog about big changes and what not. I have however, been steadily working on the project, achieving some nice ground work despite being entangled with real life. School is finally over after I had to study some more for the "fun" NYS Regents exams. Of which, I have had 3 this summer. This time it wasn't that bad though, they weren't as heartless as they were before, having two or even three, if I recall correctly, in one day. This time it was also spaced out by days between tests. State-mandated standardized testing at it's best, with the education system happily squeezing us into a mindset of learning/caring to only that which is on aforementioned test(s). *sigh*

To get straight to it..the whole deal about kuiserver being a relay for jobs, is..I daresay, pretty much done--at least on the plasma dataengine, and kuiserver's side of things. After many moments of me fighting with DBus, I am finally starting to get the hang of it. At one point, I compiled it and the dataengine, restarted plasma, started kuiserver, started a transfer, and was greeted with the awesome plasma notification. Hurrah, it works...It is kind of disheartening to think that there is really nothing to show for it, however, since to a normal person, "it did that before anyways", and you can't really take screenshots of a backend..well, I suppose you could, but what's the point? ;)

After I do some more tidying up--I still have to fiddle with CMake some more, to make kuiserver start whenever a call is sent to it, via D-Bus. Following this, I will pop a mail to the kde-core-devel and plasma-devel mailing lists, to get it reviewed for merging back into trunk, I would like to see any mistakes that I have made, as I am sure there are some, considering I am quite new to all of this, be it C++, Qt, DBus(IPC), and especially the model-view, which at some points seems to work via magic. Not necessarily in a good way, the kind of magic that you have no idea how it works, and you hope that tweaking and changing it a bit won't make it turn into Dark Magic..etc. With luck, we will catch any of those mistakes before it is sent off into the big bad world that is the people running trunk (me, for one) ;p

Well, what next? Most likely, creating the actual client that will obtain the information from the now-finished, kuiserver, and we will be painting the progress onto the icons in no time. This should be copy and paste initially, with a bunch of tweaks, to get a client up and running to ask kuiserver for the list of jobs. With said job list, it should then be able to figure out what needs to be painted on the current view, and Just Do It. It would be interesting to see what it will turn out like, how I will go about the process of doing it, or what it even *should* look like. Maybe some more glancings of the mockups could give me some ideas, and hopefully prevent me from creating some big oversight. The client will have to be somewhere near the KDirModel, no idea where yet.
So yeah, not sure what to name the client files, I am also unsure what to name the method that will be an optional call, to enable showing the progress in icons. This would be so that, for example, Dolphin could just pass this method a bool (true) to enable it, not having to worry about it any further. Well, all of these are just details derived from the bigger picture.

I also would kind of like to showcase (after this is in a semi-working state, obviously), what it looks like in action, in a screencast--since movies are so much more leet than pictures, or words, even. I have never done a screencast before, so I suppose that could be some fun, along with showing all of you what is in store for you at some point in time. All in due time..

P.S. Stupid blogger, it wouldn't let me set the time posted to the *actual* time I posted it at, I had to set it back a few hours.. *sigh*

As you may know I am a biology teacher. Next term I will teach Ecology. One part of that is the relationship between predators and prey (wolves and rabbits, for example). There are quite some mathematical model for these relationships, in school we mostly teach a simplified version of the Lotka-Volterra system.

This kind of stuff really needs a simple application to test the influence of certain factors. For example,

• what happens if after two years we kill all but 5 predators?


• what happens if after two years we kill all but 5 prey?


• what happens if after 1 year, for whatever reasons, the rabbits become more fertile?

There are tools schools can buy, but a) they suck and b) they are very expensive.

Introducing: "Predator and Prey" by Carsten Niehaus (tm)





As you can see the basic stuff all works. When happens when I start with just on predator but 20 prey but let the predators be more efficient hunters? Look here:






The application is written in PyQt4 using matplotlib. I would really like to express one thing: Python + Qt4 rocks. Seriously, the whole application has only 306 lines including comments!

Are you interested in the code or even in helping me writing a cool PP-Simulation? Do you think this should go into KDE EDU? I am hosting everything in GitHub: PP in GitHub.

I've spent much of the last week dealing with bug reports for "4.3 rc1" packages that users have downloaded from various distributions. Sadly, these packages are usually not packages of the actual 4.3 rc1 that was announced just yesterday and so I'm spending time weeding out things that are already fixed in the actual rc1 and people are spending time reporting bugs that are get closed immediately as duplicates.

The distros tried to get packages out to testers to make sure the packages worked for launch day; fair enough. KDE also spent nearly eight days between the first tagging of rc1 and the eventually final release of it; that's too long. As far as I know, no users were informed of the situation and so took to testing the rc1 packages in good faith. They have done a great job uncovering bugs we've already fixed in the process. ;)

I'd love to see our betas and rc's have much shorter tag-to-release cycles, even if developers come up with last minute fixes: just release another rc a day or two later. I'd rather have seen us put out rc1, rc2 and even rc3 if needed over those eight days.

I'd also love to see distros inform their users much more clearly what those pre-release packages are so that they test what they should be testing: that the packages install cleanly.

In the meantime, for all of our valued testers out there: if you download a beta or rc release and it hasn't yet been announced on dot.kde.org ... it's not the actual release. It's a pre-release. Hold off on reporting bugs until the announcement is up on dot.kde.org and you've updated your packages one more time to make sure you've got all the updates.

Cheers :)