KDE 4.0.1 is There For You

While the world is still recovering from the work on KDE 4.0.0, we are ready to announce the release of KDE 4.0.1, the first bug fix update of the KDE 4.0 desktop. KDE 4.0.1 contains numerous bugfixes such as stability improvements, performance improvements and, as in every point release, updated translations for most components. Lots of work has been put into shared components making the life of most applications easier. Particularly striking is also the high number of bugfixes in KHTML. Have a look at the change log for a more detailed, if maybe not 100% complete list of improvements. KDE 4.0.1 is already translated into 48 languages with more coming soon.

The KDE 4.0 branch receives regular updates, including bugfixes in trunk/ which are backported to the KDE 4.0 branch and more will appear in our monthly bugfix updates. For those following the development more closely, a shift towards the development tree that is to become KDE 4.1 this summer can be noticed. KDE 4.1 will be based on Qt 4.4 with all its performance and functionality improvements. KDE 4.0.2, with even more of the above goodness, will be released in early March. While KDE 4.0 is still rather young, we hope to be able to address even more issues people encounter while getting used to KDE 4, so make sure to keep your KDE up to date.

For those among us that prefer the more stable and proven KDE 3.5 branch, KDE 3.5.9 will be available later this month (planned for February, 19th) with an updated KDE-PIM from the enterprise branch and of course lots of other improvements.

Dot Categories: 

Comments

by Troy Unrau (not verified)

Panel is still 'huge' :) 4.0.x is for bugfixes... 4.1.0 will be new features, which already has the resizable panel. The ui is still ugly for resizing though, but at least it exists.

The problem with adding features to 4.0.x is mostly a translation problem. I expect that some distros will backport that from 4.1.x though.

Ditto for kwin effects - they are new features, and so will be in 4.1.0

Build it from trunk if you want to play :)

by Paradox (not verified)

Hang on, your saying we have to wait 6 MONTHS for a resizable panel !! Thats crazy. Frankly the ability to resize and move the panel is something that should have been in there since day 1.

I seem to recall that early on in the RC's when people were starting to get nervous about these things one of the KDE devs posted to their blog saying that adding in such feature would be 'trivial' in the new plasma framework. If it is trivial why hasn't it been done already, since obviously causing a large number of users, a lot of grief.

by Aaron Seigo (not verified)

it's there in trunk. i don't, however, want to do a long series of major merges. we've got a couple more taskbar related things coming that i'd like to then roll back all at *once* if the translators and release team won't kill me for doing so ;) essentially i want to give it enough testing now that we're this far along and get one or two more things in. 4.0.2 is realistic, if we get permission.

note that some, such as suse, have already grabbed plasma from trunk since it still works with kdelibs 4.0.x just fine.

by T. J. Brumfield (not verified)

That being said, KDE 4 isn't ready for everyday use on the desktop for everyone anyone today.

There seems to be a bunch of goodies and necessities that just missed the cut. Do all of these need to be held back for 4.1?

If the code is in trunk now, please release some of these things with 4.0.2, I implore you. It goes against the typical nature of minor releases, but the primary goal should be improving usability, and testing the code that it is written so it can be stabilized. If you merge this code, it can be tested and stabilized before 4.1.

My two cents.

by Marc (not verified)

I strongly agree... the guys of the linux action show actually said in episode 70 that they might switch to KDE 4.0 (!) but that the " freaking huge" panel 'd be a real pain in the ass.

by Bobby (not verified)

Personally I don't change the size of the panel even though it's now possible. I like it the way it is. I have a 19" monitor so it doesn't "rob" me any space. Apart from that I don't like the tiny taskbars.

by Kevin Kofler (not verified)

Indeed, those changes are not only important for usability, but most of them are also fixing regressions from 3.5.x, so IMHO they should be considered high-priority bugfixes, not feature additions.

by Iuri Fiedoruk (not verified)

+1

Removing features and then adding them back isn't the same as adding new features :-P

by Dan (not verified)

The problem is that its not just "adding a feature back"

Plasma is a whole new beast, code has to be written from the ground up. This adds huge possibilities for bugs and cannot just be thrown into any release. In addition, it requires new strings in the code, and because kde4.0 is in a string freeze, it requires some unpleasantness to either a) find strings elsewhere in the code and reuse them or b) ask the translators nicely if you can add new strings.

by Paradox (not verified)

Having the plasma backports in 4.0.2 sounds great and would go a long way towards fixing some of the pain points that people are feeling. I hope very much that it makes it in!

by reihal (not verified)

Can the panel auto-hide?

by Anon (not verified)

Not yet.

by JRT (not verified)

While I would also like to see the panel re-sizable. What you really need is auto-hide like KDE-3.

I was presuming that since these would be new features that they would not be appearing on 4.0.x -- that we would have to wait for 4.1.0 for new features.

by JackieBrown (not verified)

The svn version lets you resize or reposition the panel

by Anonymous (not verified)

The openSUSE KDE 4.0.1 packages too.

by Bobby (not verified)

I can't understand why you can't resize the panel. I just updated my openSuse packages and now I can make the panel as thin or huge as I want. Just right click on the panel and then configure it :)

by Jonathan Thomas (not verified)

Not all distros backedported the new Plasma features from trunk. OpenSuse did, though.

by Bobby (not verified)

I tell you, I just love this girl ;)

Does anybody have an idea how we could get google to write plasmoids that would integrate the google tools with KDE 4.0?

I'd love to (automatically) synchronize google calendar with KDE calendaring applications/display them on the desktop, etc. Same for google maps, Gmail, etc.

Rather than using precious development time of the KDE development team, I would love for google themselves to do it. (since they're most likely will benefit the most from it, and might make some extra money with ad revenue *hint, hint*)

I looked all over google, but couldn't find an email address anywhere, or some sort of "suggestion box". Could readers please point me in the right direction?
If interested, also vote for google to write these 3rd party apps?

by Aaron Seigo (not verified)

we'll probably have to show a large user base first. it's early days, though maybe some eager beaver googler could be convinced to dive in.

*that* said, however, one of the reasons for taking the approach we have is that it is easier to suck in other's widgets. macos x widget support is there waiting for the switch to qt 4.4; yahoo, opera, google and even vista widgets tend to just be either a URL you load into a web canvas or gloms of web cruft stuck in a package file. i would not be surprised to see us supporting all of the above within the year once we have webkit rendering to play with.

from what i recall, google widgets in particular are just a web url with a size. iow, trivial. the trick will be to integrate listings of them nicely into the Add Widgets dialog so that they are searchable / browseable and don't look overly different from a usage POV to the user.

Cool..

Sounds really complicated though. Hopefully the final version will be easier to use, than it is to explain.

I can see too many novices giving up in the future just after reading complicated instructions on various web forums.

I know it's hard - but we need to include more point-n-click settings, widgets, etc.

KDE has the hard task ahead of themselves of having to be:
* Functional, customizeable
* good for power users
* easier to use than OS-X (let's face it. We've passed Windows in functionality with the 4.0 release. =) Now we need to aim higher.)

Do you think that porting Plasma to Windows/OS-X would open it up to more developers = more and easier widgets?
Couldn't that also make "cross-platform" widgets possible?

I actually had a look at the google gadgets and it's a tiny more complicated than that...

The .gg files are a zip files which contain a manifest xml, a javascript files and other needed resources.

There seems to be a couple dozens JS functions that are probably provided by the google gadget application. I guess we'll have to either write them for plasma or, if possible/legal, use the google source.

That's why I think it would be easier if google did it themselves.

They know their code, and then there won't be any legal questionmarks.

this sounds like a job for... akonadi! :)

by Kevin Krammer (not verified)

Exactly!

Jobs for Akonadi resources to be precise

Anakondi, whatever it takes. Somebody please do it.

Google plamsmids would be great.

We use Google Desktop and Google sidebar on almost all our machines (Windows, Mac included)

Where do I go to tell Google about it?

A "Firstclass" integration would be great too. We use that program on EVERY MACHINE. Not likely though. We'd be happy with a Google Calendar and Gmail integration.

by Anon (not verified)

Given that Konqueror uses user agent cloaking to work with Google, I suspect our logged numbers on their site have gone down. So they have no way of knowing what actual market share we are right now.

Presumably, a physical mail letter campaign would have the greatest effect. It is much too easy to send an email form letter, but takes more time and effort to write a physical letter. If Google suddenly got an entire slew of these, I suspect somebody would pay attention.

Let's do it. What's the address of the right party there?

I can send a letter, will take less than 5 minutes. Have tons of stamps too I never use otherwise.

Why is Konqueror cloaked? What's the reasoning behind that?

Isn't anybody here working at google, or with google and can tell them directly?

by Max (not verified)

I'm in.

What's the address?

by Whoever (not verified)

Congratulations to the developers and keep up! Cheers!

by Hairy Groundhog (not verified)

So much khtml goodness. Are you preparing for the khtml vs. webkit deathmatch? Is it actually decided yet that webkit will be implemented for kde 4.1?

by jos poortvliet (not verified)

'implemented'? It will be in Qt 4.4, and Plasma will use it. It might have a KPart, so Konqi might be able to use it. Anything else you want to know?

by Hairy Groundhog (not verified)

So khtml is not going to be abandoned!

by Anon (not verified)

It's part of kdelibs, and so must remain and receive security updates until at least KDE5.0, which is at least 5 years away (if there is even a KDE5.0 at all).

by Nick Shaforostoff (not verified)

of course, there will be one, but maybe not so revolutionary, though

by reihal (not verified)

"It might have a KPart, so Konqi might be able to use it."

And Dolphin too, I suspect?

by logixoul (not verified)

No, Dolphin doesn't embed arbitrary KParts and never will.

by LB (not verified)

Wow, the number of changes are very impressive, especially pim3.5.9 and khtml4.0.1. Cool!!!

BTW; does anybody knows what rendering engine KDE4Live is using by default. It's extremely fast! I like it so much that I prefer browsing in a KDE4Live virtual machine, instead of my physical box.

by binner (not verified)

KDE Four Live 1.0.1 does only include khtml 4.0.1

by Kevin Kofler (not verified)

Note that if you're using Fedora, OpenSUSE or one of the other distributions shipping kdepim-enterprise (Kubuntu has been shipping some packages from the enterprise branch and some vanilla ones), you're already using most of the kdepim 3.5.9 features, as that's where they come from.

by RJ (not verified)

Does anyone have a problem with msn not connecting on kopete. I've had this problem since the 4 came out. aim, icq, yahoo connect, but msn wont

by NabLa (not verified)

I had, but after updating to 4.0.1 on Kubuntu, no more.

by RJ (not verified)

yeah I've been running the latest Kopete for a few days now, since it appeared on the new opensuse repository and it still wont connect to msn

by Michael Daum (not verified)

First of all let me join congratulating KDE for the great work and your vital development.

One question I have wrt 3.5: is it possible to backport some oft the most annoying khtml bugs from 4.0.x to 3.5, please, i.e. those related to textareas. There are some bad regression errors which almost made me switch from konqueror to firefox as my daily browser.

Thx anyway.

by jos poortvliet (not verified)

Maybe KDE 3.5.9 will fix some of those, but I'm not sure if the KHTML devs have time to backport much more...

by adrian (not verified)

i'm disappointed by the course kde4 has taken. by now it's the first bugfix release and kde4 is - for me at last - still horribly broken. i need a proxy to get into the shiny world of interwebs but that one core feature is still broken (unknown error, known in bugs.kde.org). which makes kde4 pretty much useless for me - webwise. plasma still has that don't-touch-i-might-fall-apart feel to it, global shortcuts (alt-f2 or win-r for krunner) don't work - what's that zoom feature and why the heck do i get that instead of a slim but stable desktop.

by Peter (not verified)

i dont see the point of the zoom function (upper-right corner) either..

by Luca Beltrame (not verified)

Have a look at the Plasma FAQ:

http://techbase.kde.org/Projects/Plasma/FAQ

and look under the ZUI related questions. This will give you an insight on why such a feature is present (although it's still incomplete).

by Peter (not verified)

didnt make it clear to me. i first thought it was like the magnifier but then for the entire desktop... good to see its not that (how many % of people need a magnifieR)

by Luca Beltrame (not verified)

I have struggled to find a good definition of the ZUI but I guess seeing it in action would make much more sense.
I may make a video of that as soon as a finished ZUI hits a stable release (I guess 4.1?)