A Sneak Preview of KDE 4

An anonymous reader writes "In recent times, a lot of discussion has been generated about the state of KDE version 4.0 and as Linux users we are ever inquisitive about what the final user experience is going to be. This article throws light on some of the features that we can look forward to when KDE 4.0 is finally released some time this year. The article indicates that the most exciting fact about KDE 4.0 is going to be that it is developed using the Qt 4.0 library. This is significant because Qt 4.0 is released under a GPL license even for non-Unix platforms. So this clears the ideological path for KDE 4.0 to be ported to Windows and other non-Unix/X11 platforms."

Comments

Memory

[Anonymous Coward]

"For instance, Qt 4 is designed to save lots of memory and will perform faster."

They need to work more on that cause thats the reason why I'm not using KDE. I like the UI but KDE is just to bloated so I use Gnome instead, even though I hate most of Gnome's UI.

Re:Memory

[Frekko]

This http://ktown.kde.org/~seli/memory/desktop_benchmar k.html article from 2006 shows you how much memory Gnome/KDE use. Even though it is written by a KDE member I can't see why he should have messed with the numbers. As you can see KDE actually uses a bit less (not much though) memory than Gnome.

Re:Memory

[jcupitt65]

Here's an update written by a GNOME person:

http://spooky-possum.org/cgi-bin/pyblosxom.cgi/kde vsgnome.html

tldr: they have (essentially) the same memory requirements.

Re:Memory

[swillden]

And one of the reasons to use C instead of C++ (besides the "easier to make bindings" reason) wasn't that C++ was more "heavyweight"?

Only among those who don't know what they're talking about. There's nothing in C++ that's inherently "heavyweight". Object-Oriented code often tends to be a little heavier because the tools make it so easy to generalize, and OO developers often end up writing code that may be needed someday, but isn't now. C programmers are less prone to that particular error.

However, the flip side of that focus on generality and reuse is that if it's used well it can actually reduce the code size and memory footprint, as well as making development faster and easier. You can, of course, obtain the same level of code reuse in C, but it's more effort to write and much harder to debug, so it doesn't tend to happen.

My impression of the KDE and GNOME situation is that, at present, KDE provides a richer set of libraries with more tools to make application developers' lives easier than GNOME does, and KDE does this with about the same, and perhaps a bit less memory usage. And this is *because* of C++, not in spite of it.

C++ is a bitch to learn, but once you do, it's a very pleasant language to work with, in every respect: expressiveness, power, efficiency, compactness. IMO, C++'s only practical failing is that C++ programmers are too hard to find/create (back to that learning curve). Note that I'm not saying the language can't be improved upon -- I'm comparing it to the other widely-used options, not to some theoretical ideal.

From dot.kde.org

[strider44]

I monitor dot.kde.org pretty closely and there's a few things notable here. Firstly if you look at KDE at the moment it doesn't look much different to KDE 3.x. This is because the frameworks are currently being finished and polished - the interface will be the *last* thing to be finalised - remember guys tip of the iceberg - there's a whole lot more code that you don't see than you do see.

Also, with this article specifically, a few of the graphics are temporary, most notably the background that's pretty obvious in ksysguard. Yes it's horrible for that app, no it won't be there in the finished version. It's a temporary background being used in several apps at the moment for a placeholder.

Also, the start menu isn't finalised yet from anything I've heard, that's the start menu designed specifically for Suse - it's been on Slashdot before.

KDE looks like it will be coming together quite quickly and quite soon. Several major components are pretty much complete and are being polished now. Looks like pretty fun stuff - don't believe anyone who says it's vapourware.

Re:From dot.kde.org

[strider44]

Also, a similar KDE article is at http://dot.kde.org/1167723426/

Read the comments there as well for some interesting info.

Re:Performance

[urbanradar]

It should also be pointed out that the port to QT is expected to very noticeably improve performance.

Maybe it's a typo, but just to clarify: KDE is already based on QT. It's just that KDE 4 will be using QT 4, whereas the current KDE uses QT 3.

Re:Performance

[zlogic]

Uhm, Vista runs the GUI faster that WinXP if you have a decent GPU. Just like QT4's Arthur, it uses hardware to do rendering, which is great because even when the system is under heavy load you can still do basic tasks like moving and minimizing windows. The system feels much more responsive.

Re:Windows port ?

[Anonymous Coward]

Er ... KDE4 already works on Windows. Sure, it's not 100% complete, but it's nowhere near the Herculean task you're making it out to be. KDE has always been extremely good at the Once-And-Once-Only rule, so most of the changes required are localised and very little "rewriting all of the system to make it run on windows" was required. And no, KDE4 is and will be native - no cygwin required.

http://people.mandriva.com/~lmontel/screenshot-kde 4/images.html

Some criticism of gnome mostly past

[dbIII]

I hate gnome due to the cretinous idea of implementing an obfiscated MS Windows style registry on what was at the time a non-portable linux environment - and having one of these registries per user spread over multiple files named after the three stooges and others (not kidding) in a form where you cannot export the settings to another user let alone another computer. This has been fixed to a degree, not everything needs gconf anymore and with Sabayon many of the settings can be exported. However it remains an environment where a user can render their laptop unusable via a screen resolution applet which sets stuff in the weird registry instead of in the X windows configuration files where it belongs. Try fixing that over a bad mobile phone link to a remote area some time. Cretinous behaviour like making things executable without permission also occured at one time, but I believe was fixed rapidly.

Fortunately the people that wanted a version of MS Windows that they wrote themselves running on linux (only) but not understanding the features of the platform have moved on - leaving us with two fairly decent environments with just a few remaining flaws.

Re:Windows port ?

[mrchaotica]

Perhaps you're unaware of the fact that QT, the API that KDE is based on, has always been cross-platform. The only thing that ever stopped KDE from running on Windows or Mac OS before was licensing -- it wasn't GPL'd on platforms other than unix/X11 until QT 4.

Re:NOOOOOO.......

[N7DR]

Super Karamba gets taken out by buggy widgets.

1. Right. It is also true, as you say, that it "can run for days on end"... but even running a simple bug-free widget set, it rarely runs for a week without spontaneously crashing.

2. The threading model in SK is fundamentally flawed. All widgets halt while one is updating. So if for some reason one takes a long time (network connection is down, it performs a heavy calculation, etc.) the entire SK portion of the desktop simply freezes for a length of time.

3. There is a fundamental design flaw in any system that is designed to contain objects, but which can be taken down by a buggy object.

I love the idea of SK. And I run it all the time. Right now I have 11 themes (widgets) on my desktop simply because over the course of the past few years I have found desktop widgets to so useful. But I sure hope that's it's vastly improved in KDE 4. Right now, I get embarrassed when I talk to OSX or Windows users when it comes to the subject of desktop widgets.