The KDE Project is happy to set the first beta of KDE 4.1, codenamed Caramel, free today. KDE 4.1 is intended to meet the needs of a broad range of users and we therefore respectfully request you to get testing Beta 1. Beta 1 is not ready for production use but is in wide use by KDE developers and is suitable for testing by Linux enthusiasts and KDE fans.

Highlights of 4.1 are a much more mature Plasma desktop shell that returns much of the configurability that was missing in KDE 4.0, many more applets and look and feel improvements, the return of Kontact and the rest of the KDE PIM applications, and many improvements and newly ported applications. The feature set is now frozen, so the developers look forward to using June and July to metamorphosing your bug reports into rock solid code, completing documentation and translating everything into your language. A series of Bug Days where users can contribute quality assurance to the release will continue towards 4.1's final release on the 29th of July, so watch the Dot for details.

The writer stated that the height of the plasma panel can't be adjusted, which is misleading. If one moves the mouse to the top of the new panel settings dialogue (resize/remove dialogue) then the cursor becomes a double arrow like with any other window, one can then adjust the height by pulling to the top or bottom.
Could you please mention this in your guide sebas?

Both the OpenSource AMD Radeon and the KDE team have presented huge milestones today. What is going on? I love this day :D Great work to all the developers involved! Looking forward to using KDE 4.1 as my primary desktop environment, replacing my KDE 3.5.9.

When will Qt support source events from multiple mice properly, in the sense of: I can actually use it with the usual code-less-create-more paradigm? I would love to include rotation of pieces in Palapeli based on two fingers turning around on a tablet.

Yes, he has as something meaningful. The question was:
"When will Qt support source events from multiple mice properly." I'm not much of a coder, but I understand this. Actually, I'd love to see it happen too. It'll change the way you work.

I think he wants to know when will Qt be able to distinguish from which pointer/keyboard device the imput events are comming from and treat them separately. As far as I know Qt currently can't do that and just thinks it is all comming from one input device.

Hopefully the OpenSource radeon driver now has hardware XRender. The proprietary FireGL driver does not, which results in abysmal "widgets on canvas" performance, needed by Plasma. This is on my laptop, so I don't have the option of buying new hardware (which I shouldn't have to do anyway). Proprietary drivers suck.

Thanks for the info (and the packages). Any plans for 4.1 betas/rcs to appear in F9 repositories (testing perhaps?) or just the final release - if I've understood correctly then 4.1 should appear as an update for F9 after release like the 3.5.x updates used to in earlier Fedoras?

Hopefully is clear above but this is intended as a 'what are your plans'/'how do you see this working' kind of question rather than a 'give me 4.1 in Fedora 9 now!' demand :-)

We're planning to push it to updates-testing once it's officially released, then to the stable updates when/if testing went well. We don't want to push it to testing right now because we still need updates-testing to test 4.0.x bugfixes.

Only the new kde 4.1 betas will be pulled in. I have been using this for a day and have to say that I am yet to find bugs in anything but plasma and possibly, kwin. KMail works very well with disconnected IMAP.

Good point, cheers. I think I'll discipline myself to hold off for a few days though until my main system is up and running again (from hardware breakage) then I can afford to try this (or even full rawhide) on my old laptop, which to my surprise runs kde4 nicely, even the composite stuff

I have a pretty recent checkout of KDE PIM and I've had very few problems, everything works as expected, it hasn't eaten any of my emails. The only problems I encountered were in trying to add new feeds to akregator manually, but once I exported my feeds from kde3 and into kde4 everything works great.

That's perfectly possible. However, the current ScriptEngine api doesn't allow you to do very much, and only C++ is supposed to use the full Plasma api. C# isn't really what I would call a 'scripting language' anyway, and really people will expect to just be able to use the C++ api. So technically it is possible, but I don't think it would fit in very well with Aaron and the Plasma team's idea about how non-C++ languages should work in plasma.

Yes, more bindings developers are always very welcome. At the moment Arno Rehn and myself are mainly doing the C# development. You don't have to actually work on the bindings themselves, there are plenty of things to do, like translating the Qt C++ examples to Qyoto/C#, or adding docs to the TechBase wiki.

The C# bindings use the same 'Smoke' library as the Ruby and PHP bindings, and recently Arno has made a major improvement to the way Smoke works, which will allow us to wrap a whole pile of KDE4 apis. Arno wouldn't have starting working on bindings if the C# bindings didn't exist, and now he has made a great contribution to improving both the PHP and Ruby bindings too. So one reason I wish people wouldn't keep being rude about Mono/C# is that this is an example of how the C# bindings development has helped the KDE4 bindings 'eco system'. If you don't like C#, please use other languages like Python or Ruby (we really don't mind), but as a language geek I think it has some nice features and a 'personality' of its own when used for Qt/KDE programming.