KDE 4.1 Beta 1 Released

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.

For more details, see the release announcement and info page or if you are at LinuxTag, see KDE 4.1 being presented in Berlin this Friday.

Dot Categories: 

Comments

by sebas (not verified)

For those wondering how this Plasma thing works, I've written down directions how to use its various new features on my blog at http://vizZzion.org/?blogentry=817

by Luca Beltrame (not verified)

Very nice. Sebas, would you mind giving me permission to reproduce/reuse those for the Plasma FAQ (which should move from techbase one day or another... too little visibility there)?

by sebas (not verified)

Yes, please use it.

by Bobby (not verified)

I just read a brief review of KDE 4.1 Beta 1 on Ars: http://www.osnews.com/story/19803/Ars:_Plasma_Continues_to_Advance_in_KD...

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?

by d2kx (not verified)

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.

by JLP (not verified)

Yeah, lots of good news lately. Also MPX has been merged into xorg master : http://lists.freedesktop.org/archives/xorg/2008-May/035641.html

by Stefan Majewsky (not verified)

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.

by Richard Moore (not verified)

What are you asking? I'm not sure you've actually included a meaningful question, please explain.

by winter (not verified)

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.

by JLP (not verified)

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.

by NabLa (not verified)

I thought this was X's job...

by panzi (not verified)

Yes, but Qt is an abstraction layer and hides platform dependent code away. It also hides such special features away, unless support for them is explicitly implemented.

by S. (not verified)

Wrong: http://doc.trolltech.com/4.4/qtabletevent.html#uniqueId

What would need to be done to make it nicer, would be to generalize this support to QInputEvent, now.

by David Johnson (not verified)

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.

by anonymous coward (not verified)

Excuse me, what did the oss radeond river guys do today? I cannot find anything on the web about it?!

by Kevin Kofler (not verified)

That's not it, it's some proprietary SDK. :-/

The really interesting news, which is what was referred to in this thread, is this: http://airlied.livejournal.com/60180.html

by Paulo Fidalgo (not verified)

Since fedora ships KDE 4 by default, it will ne nice to have packages to test this beta...
Anybody want to step in, and make some rpm's?

PS: I cannot switch to other distro, but I would like to test and report bugs, while I'm at work.

by Rex Dieter (not verified)

Patience grasshopper, coming soon. :)

by Kevin Kofler (not verified)

It's in Rawhide now. But be warned, Fedora 10 isn't even alpha yet, so Rawhide is a bit bumpy right now.

by Simon (not verified)

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 :-)

Cheers,
Si

by Kevin Kofler (not verified)

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.

by Simon (not verified)

Makes sense. Thanks for the reply. I'm liking KDE 4.0.x on Fedora btw, seemed like a bold move making it default in Fedora 9 but it is working for me

by Ravi (not verified)

All you need to do is the following on an up-to-date Fedora 9 system:

yum update 'kde*' soprano 'extragear*' --enablerepo=rawhide

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.

by Simon (not verified)

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

by Paul (not verified)

"On 29th May 20008"... Seems a bit TOO behind schedule for my liking.

by Will Stephenson (not verified)

Fixed, ta.

by ad (not verified)

How stable is KDE PIM for KDE 4?
Would you guys recommend it over the KDE 3 version?

by Aaron (not verified)

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.

by ad (not verified)

Great :) Are you using IMAP by the way?

by Luca Beltrame (not verified)

I briefly (~5 min) tested disconnected IMAP on KMail from trunk and seems to work as expected. I'll try to test more during next weekend.

by Kishore (not verified)

I have been using it for my mailing lists for about a month now and it's been mostly fine. Minor issues but never has it chewed on my mail! :-)

by Kishore (not verified)

I have been using it for my mailing lists for about a month now and it's been mostly fine. Minor issues but never has it chewed on my mail! :-)

by Damnshock (not verified)

It is quite stable but not absolutely. For example, every time I try to open an attached image in on of my emails... CRASH!

However, his is the only problem I've found so far.

by A. L. Spehr (not verified)

Keep your eyes out for a kde pim krush day, in which we will look for bugs.

by taerde (not verified)

does the new krunner have the possibility to run a program as another user? i could not find this when i tried the beta.

thanks to all the developers, beta 1 looks great!

by Darwin Reynoso (not verified)

we need a plasma binding for c# :-)

by Richard Dale (not verified)

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.

by ad (not verified)

Yeap C# is not scripting at all. I'd much rather get Haskell bindings.

Of the all the scripting languages with plasma bindings available, is any of them statically and strongly typed?

by Luca Beltrame (not verified)

Are there any examples of ScriptEngine usage with some languages? I'd like to get my feet wet with Plasma using Python.

by Jonathan Thomas (not verified)

+1

by S. (not verified)

Seconded. Thanks. :)

by Sebastian Sauer (not verified)

Well, SuperKaramba [1] integrates as ScriptEngine into Plasma and allows to use Python, Ruby and JavaScript.

[1] http://techbase.kde.org/Development/Tutorials/SuperKaramba

by Stefan Majewsky (not verified)

We also need more developers working on C# bindings. (Just in case we have enough and I'm not aware of that, we need even more developers. Remember Steve Ballmer's well-known speech.)

by Richard Dale (not verified)

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.

by Ian Monroe (not verified)

It is great you have large amounts of code sharing between the languages and have someone hacking on Smoke. QtRuby rocks so much. :) It's so much fun to code in.

by Velvet Elvis (not verified)

Just keep it out of core. Just because Gnome swallowed the Trojan Horse doesn't mean that KDE has to. Keep that filth off my hard drive.

Lua bindings on the other hand . . .

by Satin Elvis :P (not verified)

+1, agreed. Better languages FTW.

by noorker (not verified)

+1, I don't want Mono on my harddrive.