Submitted by The second beta for KDE 4.3 has been released. The highlights of this release are the integration of many new technologies, such as PolicyKit and Geolocation services, new window animation effects, a more usable run command popup, many new and improved addons in Plasma, Many bugfixes and improvements across all applications, and more integration of features coming with the KDE 4 platform.
Hmm… some pretty interesting plasma addons…
# Weather wallpaper displays a wallpaper matching the current weather
# The Virus wallpaper slowly eats your desktop
# Mandelbrot fractals as real-time computed wallpaper
# Marble Interactive desktop globe can be used as wallpaper
Still no animated wallpapers like E17 has, but I’m sure that’s coming.
# Spacers for the panel
This is very nice, but more like a workaround… at the moment, some elements on the panel take up tons of space and then center themselves with giant empty margins. Presumably now we’ll have more control over where things go…
One of these days I should put in a request (or add to someone else’s request) for a vertical taskbar. I keep two vertical panels on the sides of my screen, because I have a lot more width than height… A vertical taskbar would actually be USEFUL.
Well, as soon as anyone writes such a wallpaper plugin, it’ll be there… It’s been possible since KDE 4.0, apparently there is little demand considering how easy it would be to write one (javascript, python and other languages can be used and support for video is available).
It’s true that the current taskbar isn’t great on vertical panels. I personally would love to see improvements in that area – again, someone with some javascript fu would already get a long way…
> Still no animated wallpapers like E17 has, but I’m sure that’s coming.
well, actually there is some experimental code to load E17 wallpapers, it’s still unreleased tough
# Spacers for the panel
> This is very nice, but more like a workaround… at the moment, some elements on the panel take up tons of space and then center themselves with giant empty margins. Presumably now we’ll have more control over where things go…
in 4.3 this doesn’t happen anymore, widgets in panels are kept at a “reasonable” size, unless they really want to stretch (like the taskbar)
> One of these days I should put in a request (or add to someone else’s request) for a vertical taskbar. I keep two vertical panels on the sides of my screen, because I have a lot more width than height… A vertical taskbar would actually be USEFUL.
just drag your panel to the side of the screen and voil~A
It seems KDE is really going somewhere. There trying to seperate the desktop manager from the OS, a bit like Mac. Sadly it still crashes a lot here so I keep using Gnome for a while. But I admire what those guys are doing.
You are most likely using the wrong distro. Try a distro that integrates KDE well.
indeed. 4.3 proves pretty stable for me, and it’s not even released.
Is Konqueror stable yet?
You’re asking for a stable *webbrowser*?!?!? I dont believe there IS such a thing… Besides, it depends too much on the sites you visit, I suppose. For me it’s pretty stable, and I’m updating SVN daily on a running KDE…
What distro integrates KDE well? I tried KDE 4.x in openSUSE 11.1 recently and that was an absolute trainwreck for speed and usability. I never had KDE crash or cause an error, however the whole thing was laid out in a very illogical and slow to access manner. To make matters worse, it did not even look great. I was expecting at least some nice themes and effects and was severely let down when I could barely go 5 minutes without a few things looking completely out of place.
The whole thing was so bad I even installed it on a laptop at work and asked people to tell me what they thought of it (side note: everything here for new Linux installs is Ubuntu LTS). I had no positive reactions, and the most common complaint was that no one could find anything in the clown-car nested menus and that it was ugly.
I really want to like KDE 4.x since they seem to be developing a lot of great future content for it, I just want them to really clean up the fundamentals first. Either openSUSE is implementing KDE horribly, or I simply do not get it.
Edited 2009-06-11 22:08 UTC
Mandriva seem to have a good (and up to date, not like OpenSUSE) integration. But compiling it yourself is easier than in KDE3. It is the best way to have uptodate and complete KDE. The crash come from the fact that distributions crop part of the code to avoid some dependencies and stuff like that. Separated packages are less reliable than meta packages (kde-base, kde-graphics, kde-edu and so on).
Mandriva has got the best KDE integration. Last time I used Suse (it was 9.1) it was indeed very slow and heavy on the resources. Maybe Suse’s latest version is better, I don’t know. I’ve stopped using Suse after the Microsoft patents deal. IMHO Mandriva has got the best KDE and Fedora the best Gnome.
Yes, it’s your fault it KDE crashes, try better next time.
The only thing that stops me from using KDE (and thus *nixes) is that I really hate Konqueror’s interface. I’ll wait for Opera to come on KDE4..
I don’t get it? You _can_ use Opera on KDE4 without any problem, but it will never be part of KDE couse it’s closed source.
I think what he means is the Qt4 version of Opera. I like konqueror but given they refuse to drop khtml in favour of webkit, I’ll be sticking with GNOME. The whole khtml versus webkit is a prime example of where politics are taking precedence over adopting something that would improve the end user experience.
This has nothing to do with politics. It has to do with the fact that the API was locked down when 4.0 was released. Replacing khtml with webkit would cause break that.
Furthermore they are trying to integrate as much as they can from webkit into khtml, but only as long as they can do it without breaking the API.
Perhaps they will consider bundling webkit alongside khtml and then slowly depreciating khtml so that it’s still there for backwards compatibility, but also make webkit available.
Mate, they broke API compatibility when they moved to 4.x – they might as well done the full monty and trashed the kjs and khtml at the same time – they had the opportunity whilst they were breaking around inside and now they’re screwed until 5.x is released before they can break compatibility. It was a political decision because the door was wide open to massive changes but they refused to make them. How KDE is saddled with a backwards out of date rendering engine that is so far behind the times it makes me cry.
As far as I know, these are the facts:
i.) The KDE devs can not drop the khtml kpart entirely during the KDE4 cycle due to their commitment to binary stability and compability and the fact that the webkit integration in Qt4 seems to have been not ready for primetime at the time KDE 4.0 was released.
ii.) The webkit kpart is actively developed and can be used as off now instead of the khtml kpart (In konqueror View -> View Mode -> Webkit if it is installed). I’m not aware of any distro defaulting to the webkit backend or even providing it out of the box (although it is in kdemod-playground for arch linux users), maybe because the last time I tried it several months ago it offered little advantages above khtml (including gmail + modified UA string for kthml) and seemed to be a little bit less stable than the default one. Of course, ymmv. Note that besides those places where the kpart is used, the default is – afaik – to use the WebKit integration in Qt (for example in plasma).
iii.) KHTML is also actively developed (in fact, khtml pretty much has the lead wrt quantity of bugfixes in the changelogs for the 4.2.x series). The debate whether khtml should be “actively” depreciated or not is – again, afaict – not decided yet, but I would guess that as long as the (compareably small) team of khtml developers actively develops it and because of i.), khtml will remain a part of KDE at least for the whole KDE 4 family of releases.
iv.) The need for a dedicated webkit browser will hopefully be addressed by rekonq (or whatever its future name will be) in the soon future (I’m typing this from rekonq which I try to use for all my browsing where zotero is not needed) which is now a bona fide KDE application. It’s currently at version 0.1 and has more rough edges than polished ones, but it works most of the times and – thanks to the quality of the WebKit integration in Qt – seems to be picking up quite some steam recently. For those who prefer a pure Qt project without KDE dependencies, arora does a good job and seems to be atm a little bit more mature than rekonq.
Please note that I don’t want to point any fingers, since there are a lot of reasons why people prefer GNOME over KDE (and vice versa, whatever floats your boat, etc.). But KDE’s inability to depreciate the khtml kpart and/or scrap konqueror strikes me as an odd criteria, since – and please correct me if I’m wrong – GNOME has no unified way to incorporate HTML content into it’s desktop either, at least this is the impression one gets from reading
http://blogs.gnome.org/otte/2009/03/03/browsing-in-gnome/
which dates back only three months and most users I know tend to think of Firefox as the default browser for GNOME, probably because most distros don’t advertise epiphany (with which I have a hate-hate-love relationship, but that is for another post). Sure, epiphany with webkit is more mature than the compareable stand-alone projects on the KDE side of the fence, but as of version 2.26.1 here on arch linux, it still seems to default to the gecko engine while (for example) midori is subjectivly in a comparable state to arora.
Side remark:
Besides the fact that the decision to promise (and adhere to that promise) binary compability throughout a major relase is a political decision, I fail to see anything else that is beyond the typical “developers are free to work on whatever they like to work as long as you don’t pay their wages” problem/feature, that is inherent to all FOSS development. You may argue that KDE should probably have had alternatives to konqueror like rekonq higher and earlier on their agenda (and I would agree to that), but I’m not sure if it would have been wise to drop a (compared to the state of affairs in KDE3) working default kpart, most likely resulting in additional feature regressions and instabilities, while the whole DE underwent a massive restructuring with well documented growing pains and regressions galore. Also, I would not rule out that the ongoing debates around dolphin/konqueror and the “omg they killed konqi” complaints from loyal konqi users played a role in the decision to at least keep konqueror as the default web browser. Remember: One mans gold is another mans prehistoric relict from the past which should be scraped in favour of something different, immediatly.
I’ve been using Firefox with KDE for a long time… I don’t really see a problem with using GTK apps in KDE. (although using QT apps in Gnome tends to be ugly)
So, do you avoid Windows as well because the interface for IE is so ugly, and you’re waiting for Opera to come to Windows?
Same situation.
(Yes, that’s being facetious, as Opera is available for Windows, just like Opera is available for Linux, which means the whole argument is moot, and the OP is nothing but a troll.)
Gahh I should keep track of the comments I post. I use Opera on Mac, Windows and Linux (If I’m using Linux) and there are native skins for opera and windows. On linux there isn’t one cuz it uses the native widgets of Qt3 not Qt4. That’s quite bothersome to me.. Maybe you should think for once before you go about calling people trolls. I see that I missed out saying “at the moment” cuz I’m using Win7 instead.
And if further clarification must be provided; yes I did use IE7 on Vista because other browsers stood out ugly due to lack of aero until Chrome came out. You can simplify the IE7 and 8’s interface to make it more palatable, but I couldn’t do that in case of Konqueror.
Edited 2009-06-13 15:12 UTC
Atleast in Arch there is a Qt4 port of Opera:
http://aur.archlinux.org/packages.php?ID=15228
I’ve used is some time and it works great.
Correct me if I am wrong but I have noticed with every new and major QT release, KDE has been rewritten from scratch. This is why I believe KDE will not progress with time because all they do is rather than improving what already works, they scrap that and they decide to re-write the whole thing. They keep re-writing things. Imagine what would happen if MS decided to re-write Windows from scratch with every new release or to be more realistic, re-write Explorer. Instead, they are just improving stuff. Since KDE is being re-written from scratch with every new major QT release, it only shows how incompatible QT is with older libs. With WIN32, run a W95 app in Windows 7, it will still probably work.
On the other hand, both QT and KDE are way more sane platforms to develop for, API-wise speaking. They don’t rewrite stuff just for the hell of it, they do it to be able to apply further improvements.
Anyway, your comment isn’t really very accurate: There are many, many Win32 apps that stopped working with different versions of Windows, starting with Win2k and even between different Service Packs much later. As many found out when the Win2k got leaked, MS has gone as far as hacking the OS to mantain backwards compatibility, mostly because they have a massive workforce that can work in both fronts: compatibility and new features. And even then, Vista took a very long time to see the light (and failed miserably ultimately).
In any case: this is the way KDE and many other F/OSS projects work. You’re free to use them or not
Not much of KDE have been rewrited for KDE4. And nothing was almost rewiten between KDE2 and KDE3. Exept Amarok, KOffice and Kicker/KDesktop, much KDE-apps have just been ported. KDE4 offer new api that allow developper to drop some old hacky/duplicated code and many application are slowly migrating to those API, but that’s not a rewrite at all. KDE-pim have not been rewrited to use aKonadi, nor kopete for decibel, nor Amarok for phonon, nor K3B for Solid, they just use those technology and dropped old unix specific code.
KDE has been rewritten two times, from KDE1 to KDE2 and from KDE3 to KDE4. Given the time that it has taken to get KDE4 in a usable form, I suppose that KDE5 will be like KDE3, a direct port of the existing platform and maybe they will rewrite everything for KDE6 but that is some years ahead from now.
Microsoft actually did have a significant rewrite when they switched from the 9x kernels to the NT kernels and userland. They just happened to put in a lot of work to make sure that there was backwards compatibility. Qt and KDE could have chosen to do that, but since this is the open source world, it’s better to just have people port to Qt4/KDE4 than waste time making backwards compatibility shims. You can also have both Qt3 and Qt4 installed side-by-side, so you actually get free backwards compatibility by just installing both. You can still easily run KDE3 programs on KDE4 systems.
Qt4 is backward compatible with Qt3 (well, you have to hack the code a little) with Qt3-support, but those function are tagged deprecated and will be removed. Using Qt3 support also prevent KDE from working fine on osx because Qt3-support use carbon and Qt4 use Cocoa