KDE today celebrates its semi-annual release event, making available new releases of the Plasma Desktop and Netbook workspaces, the KDE Development Platform and a large number of applications available in their 4.5.0 versions.
In this release, the KDE team focused on stability and completeness of the Desktop experience. More than 16,000 bugs have been fixed, and many feature requests have been filled. The result for the user is a system that feels faster, takes less time to "think", and works more reliably. The large number of bug fixes goes accompanied with many parts that have got an extra portion of tender loving care. Plasma 4.5.0's new notification system is one example here. It is designed to get less in your way, yet to support your workflow as smoothly as possible. Visually, the striking monochromatic icons make for a more consistent look in the notification area. A highlight of the KDE Applications 4.5.0 is surely Marble, which can now be used for map routing as well as viewing. The Konqueror web browser can now also use the WebKit engine to render its content. The KDE Development Platform 4.5.0 offers a new generic cache for applications that need high-speed access to certain data, such as icons or other pre-rendered artwork. The new KSharedDataCache speeds up loading of many components, while the new HTTP scheduler is optimized for concurrent access to web servers, and makes loading of pages in Konqueror and other parts using the KIO HTTP mechanism faster.
Today's releases are the first in the 4.5 series and will be followed with updated versions approximately monthly that will focus on fixing bugs. The next feature releases are planned for January 2011. If you would like to test-drive 4.5.0, you can do so by installing the packages that should be made available by your operating system vendor. You can also choose to build 4.5.0 from source, the nitty-gritty of that can be found on TechBase. For the impatient, there is also a Live CD available.
Comments
Where are kdepim, kdepim-runtime?
they will come in 4.5.1, since the change to akonadi isn’t polished enough yet — and noone wants to risk that KDE users lose their emails…
Sounds like a good plan. Compiling as we speak.
Actually, I don't think we'll make 4.5.1 for the Akonadi-based PIM. It all depends on how the beta phase works out. Migrating Kontact to AKonadi is a pretty big step, so we don't want to rush things here.
Kontact 4.4 is still actively maintained and continues to work, so that's what users will use in 4.5. We did not upgrade the version number of KDE PIM, since it's essentially what's in 4.4, anyway.
There will be a beta of Akonadi-PIM in the next days, and from there we'll see how it goes. The PIM team pays special attention to migrating your data, and if the new Kontact doesn't work for you yet, it's easy to switch back as config will be retained for both versions, also cached data (such as disconnected IMAP accounts) can be kept if you're not sure you're ready to switch.
I tried KDE PIM 4.4.92 (Beta 2), and I must notify you that it has, depending on your point of view, finally reached beta quality. It qualifies, indeed, for a Beta 1 moniker, but it needs a lot of testing, because several betas should be done and the whole thing isn't expected to be stable until KDE 4.6.0.
Can you test? I make a pledge to test this, because this is the first of a new wave of features that will surely put the KDE desktop ahead of the curve.
I'm with you. I don't see why there should be any hurry in releasing it as stable. To have it tested by many users the important part is having it packaged, distributed and promoted. Mplayer was being used by tons of people in its Beta and RC days, long before it was promoted to stable. I remember everyone installing a Beta of KDE 2 that came with some SuSE release a long time ago.
So just make it possible to install these Betas along with the latest stable, and get distros to distribute it as an option during the KDE 4.5 life cycle.
System is already running at full force to get the new version!
Got to see the improvements over RC3!
Many thanks to all KDE hackers (including documenters, translators, PR people and all the others) for getting 4.5 done!
KDE PIM was been delayed and was not part of the 4.5.0 release of the Applications modules. the new version of KDE PIM is expected to be made in tandem with the 4.5.1 release.
for a summary and links to sources on the matter, see: http://forum.kde.org/viewtopic.php?f=20&t=89366&p=165898
After discussing this with the PIM team, we're not sure we'll make 4.5.1, though. A release still this year does look realistic, however. See also my comment above.
Better safe than sorry. :)
On the other hand - the message has been "delay from 4.5 to 4.5.1" and therefore your message "still this year looks realistic" is not a very good signal.
It leaves me with the impression that it is quite probable that the release will not be available before 4.6.
If they now targets KDE SC 4.5.3/4/5 or even 4.6 I find the "delay to 4.5.1 message" to be really awkward.
It's the communication bit I'm after - not the potential delay. :)
Wouldn't it make sense just to finish it properly and to get rid of as many regressions as possible then ship it with 4.6?
I agree. I rather see it released as part of KDE 4.6.
IMHO, it was a terrible idea to move release of the Akonadi-based KDEPIM suite to 4.5.1. Doing that, it misses all the testing it would have received from the 4.5.0 betas and RCs.
It's big enough of a change that it should get this testing. I don't want to lose my e-mail!
In tone with the Akonadi/KMail testing, can you provide us a tarball with Lion Mail? I really want to exploit some of the advantages of the new framework.
Would it be possible to provide seperate feature packages, so that we can already test it? I don’t want to switch to the full KDE trunk to get PIM 2, but I do want to test KMail 2.
(I’m on Gentoo packages)
And there's still one application that holds me back on KDE 3.5.10: KSensors.
Temperature Sensors from KDE 4.x show only temperatures, so, please stop advising them.
I would also become happier if someone ported KNetStats (yes, I know about KNemo, but the former application is more lightweight).
And I expect KDE developers to start working on optimization and solving old bugs (and there are hundreds of them) for KDE 4.6 and onwards. Most of us need a stable and fast DE, not a shiny bug-ridden and prone to crashes one.
Can't you simply use KSensors from 3.5.10 in KDE 4.5?
I want to get rid of Qt3/KDE3 libraries once and for all.
That's the only reason of not willing to use any KDE3 applications under KDE4.
I can understand that, just like getting rid of GTK+/Gnome libraries and all that. But needing a particular Qt3, KDE3, GTK, or Gnome application isn't really a reason not to move to KDE4.
Gnome is a whole different matter, they care about compatibility. GTK applications circa 2003 will still be working in year 2010.
KDE3/Qt3 are *officially* abandoned, thus it makes zero sense to have them installed once I've upgraded to KDE4.
Gnome is a whole different matter, they care about compatibility. GTK applications circa 2003 will still be working in year 2010.
But likely not in 2011, or maybe 2012, whenever GTK3 comes out. ;-)
A program like KSensors will likely still just work, so it's totally not a problem using it. If you need support for it which includes development, you're out of luck of course, but saying that if upstream is not working on it anymore make "zero sense to have it installed" seems quite unpractical. Sure, it would be nice to have every single application that ever was available based on KDE3 available in 4, but that's likely not going to happen. There are thousands of other, new applications in its place of course.
Don't get me wrong, I'm sure you've good reasons for stating the above, it just doesn't seem to be the most ingenious reason for not using some piece of software you otherwise really like.
Or maybe you should just install the GTK version of KSensors from 2003 for now. ;-)
Your chain of reasoning just ended up justifying sticking to KDE 3.5.10 with the fact KDE3/Qt3 are officially abandoned.
I get your point, that said in practice for your case none of that matters. For now KSensors of KDE 3.5.10 works better for you, so use it.
BTW, he said that KDE4 sensors show only "temperatures". I see the sensor list in KSysGuard and I can get a full list of status indexes. Really... what am I missing?
> Gnome is a whole different matter, they care about compatibility.
Ugh. implying KDE doesn't?
All 3.x releases are compatible.
All 4.x releases are compatible.
That's the point of the first number anyways, for a lot of projects. They only increment the first number to start a whole new series (in our case, the 4.x series). KDE guarantees compatibility between those versions. An application that's compiled for 4.2, will still run when you install kdelibs 4.5.
Same logic applies to GNOME: their 3.x isn't going to be compatible with 2.x
As far as I know that's not entirely true. Packaging KDE 3 and 4 at the same time (well, just the libs) is not as easy as it may seem, and not all distros did it 100%.
At the pre-4.0 times, much work was done in trying to make that not as painful, but still is not as easy as with plain Qt applications.
KDE3/qt3 are stable and mature. For stable and mature software maintenance is marginal. So even when they are officially abandonned upstream you can still use and run and fix them, like you can run applications with DOS 5.0 as many in industry do.
Even this seemingly innocuous message gets modded down.
I love KDE fanboys. Keep on voting!
Maybe it's because your comment comes over a bit demanding and at the same time narrow-mminded. It sure is easy blame critique you get for your comments on some fanboys, but maybe there's just this tiny little bit of truth in those reactions telling you that your comments are a bit clueless. Just saying, it's not always someone else who's wrong ...
I think KSysGuard's sensor sheets can do everything KSensors can - and more.
can we? or at least for some websites, like browser identification?
Settings ---> Configure Konqueror ---> File Management ---> File Associations ---> html ---> goto Embedding tab and there put WebKit (kwebkitpart) on top. Hope that helps :)
I have been using 4.5 since its first RC and it has been a breeze. The last remaining annoyances have been fixed in the final version (thanks for the delay). :)
So thank you to all KDE developers. You are doing amazing work!
All KDE developers and contributors for this great release.
What is the plan for 4.6 BTW ? :)
See the Feature Plan, but keep in mind it may be incomplete and these are always subject to change.
and I like aseigo blog posts talking about future plans ;)
It sure is awesome! Can't wait for 4.6 :)
"More than 16,000 bugs have been fixed"
Does this count the duplicated bugs?
I don't know, but I would guess it's basically the count of all bug reports that have been closed since 4.4.0. That likely includes many duplicates.
Still, it's an awe-inspiring number. Even if many of the bug closings represent relatively little in the way of improvements to the code, try just sitting down and counting to 16,000 some afternoon. I bet it would heighten the appreciation for how much work has gone into this release :-). Go KDE team!!
I also am fine with the idea of KDE-PIM releasing with 4.6. I've always thought it was a bit odd the idea of making a major change at 4.5.1, so in a way I find this more satisfying.
That would be highly misleading and I hope it's not the case. You can close bugs with WONTFIX, INVALID, WORKSFORME, DUPLICATE, etc. Counting all of those as fixed bugs would be pretty ridiculous ... "nah I won't fix this one, there you go one more bug fixed!".
Whatever metric is used in the release announcement, it is wrong. A lot of bugs are never reported, yet fixed. So how do we count those? If we would only count reported bugs which have been fixed by a code commit, yes, the number is smaller. No, it is not more accurate. Many bugs are closed because they have been fixed in the mean time - WORKSFORME is often used there if the developer who fixed the bug never saw the actual bugreport...
So the marketing team simply uses the number of bugs closed in the period between releases. Works fine - you also credit the work of the bug squad with that number. Even on WONTFIX bugs you have to spend time...
The fact that there isn't any accurate metric doesn't make this approach acceptable. It's so bad that it's not even funny.
If you're going for that number better claim "bugs reports closed" instead of "bugs fixed". Or else chose only the ones marked as "fixed" and use that as a lower bound.
what they did was fix bugs that users reported.
But why don’t you give them a hand? I’m sure if you can write a simple way to get a more accurate number, they’ll gladly take it :)
(provided you make it as easy to use as the current one)
Face the reality.
On the other hand, they will release beta after beta during the KDE 4.5 cycle (with every minor release, a beta, starting with Beta 2/KDE 4.5.0). And if we don't test these betas, then Akonadi/KDE-PIM release is going to be a flop.
So, IMHO the message is clear. Download and install Akonadi/KDE-PIM Beta 2. Test it. Report bugs. Hammer it.
(and also, Sebastian... could you release a tarball of Lion Mail to sweeten my Akonadi/KDE-PIM testing?)
Yes, it includes all bugs that get closed, for all projects that track their bugs on the KDE bug tracker, i.e. it also includes koffice, amarok, digikam, kdevelop, etc.
Still the number is a good indication about how much work the team did, as each of those 16000 bugs is usually closed individually.
On the other side there is the number of bugs opened. It is a good indication about the work YOU did :) And comparing those numbers, you did a better job then the KDE team: Around 16000 bugs closed, around 18000 bugs opened in the last 180 days, so you could say that we have 2000 more bugs :)
You can use bugs.kde.org search service to find how many bugs really got closed as fixed. For example, in the last 180 days around 4600 bugs have been closed as FIXED. Again, this includes all projects. Plasma alone has 700 of those fixes. Additionally, around 600 feature requests have been closed as FIXED (50 in Plasma).
But only mathematicians care about numbers. What really counts is that bugs continue to get reported and continue to get fixed. That's the heartbeat of the KDE project.
Keep beating!
Thanks very much to the KDE team for it's time dedication and hard work.
The first thing that I tested was Dolphin, which seems to be good now, stable (after RC3) and fast.
KDE SC 4.5 seems to be quite stable and polish. The only two little problems that I have are the start up time and Bball is still not fixed. Although it's a very responsive Desktop it seems to start up a bit slow. KDE takes longer to start up on my systems than openSuse 11.3 itself.
Haven't noticed it taking any longer than 4.4 did on Fedora. Certainly nowhere near booting time. Sounds like you have some particular issue.
Hi,
thanks for this nice release. I use Kubuntu 4.5-backport packages for Lucid and notice that Klipper does no auto-collapse anymore. Is this a bug or a feature (or Kubuntu ;-)?
Bye
Thorsten
ctrl-alt-v doesn't bring it up anymore...?
Nope, nor in Kubuntu - https://bugs.edge.launchpad.net/kubuntu-ppa/+bug/616370?comments=all
Clearly a bug. Please ask the Fedora developers to upgrade their dbusmenu-qt packages, as this has already been fixed some time ago.
I wasn't really comparing the login time to that of KDE 4.4. I really meant the general login time of KDE 4. OpenSuse 11.3 takes 30 seconds to reach the login screen on my laptop and KDE 4.5 takes 38 seconds to boot the desktop after that. However, if I log out and then log in again then it takes only 10 seconds. It's only the boot up login that seems to be so slow.