“The latest in the 4.x series of the KDE Software Compilation is due to be released in early August 2010. With the first beta of this release recently unleashed, I thought I’d download the openSuse packages and see what 4.5 has got in store for us.”
“The latest in the 4.x series of the KDE Software Compilation is due to be released in early August 2010. With the first beta of this release recently unleashed, I thought I’d download the openSuse packages and see what 4.5 has got in store for us.”
I tried SC 4.5b1 for a few days. Overall I found the experience to be OK, but considering it’s only at Beta 1 stage, nothing mind-blowing could’ve been expected.
I liked the reorganization of System Settings. IMO it’s a huge boost in usability.
I liked the general idea behind the Systray tweaks, but in Beta 1 the execution still lacks: The “expand arrow” and the “notification i-icon” switched sides without apparent reason. Kinda felt Ubuntu 10.04-ish. I hope that in the upcoming betas the Plasma team either switches the positions back again or reveals to us why the change was made. 😉
Giving the systray icons a dbus-based menu (probably the first somewhat major contribution by Canonical to KDE ever) is also great in theory, but it requires a yet-to-be-released version of Qt 4.7 to work properly (with Qt 4.6 and the current 4.7beta you lose all icons in context menus).
I didn’t try KWin’s tiling feature. I’m on a 15.4″ notebook, so I guess it’s to few screen space anyway. I also am still getting used to KWin’s tabbing feature that was introduced in 4.4.
I — for now — switched back to SC 4.4 because of the following regressions:
1.) I like dark Plasma themes, but Oxygen is currently not tweaked for the new systray (only the light Air theme is).
2.) Qt 4.7 is currently way too buggy. It can’t remember list sorting which is really annoying in the address book (contact entries are ordered randomly and not alphabetically).
3.) Something caused KWin to require 10% CPU all the time. It wasn’t a regression in KWin itself, because downgrading KWin alone to 4.4 didn’t help.
4.) The QuickAccess applet crashed Plasma.
5.) The combination of new Systray and Qt 4.7 don’t work well with tray icons spawned by older Qt applications: VLC and Skype generate a 16×16 window which is visible all the time when the tray icon is also visible (should be fixed when the application authors recompile their apps).
While I was annoyed by those bugs, I have to say that for a Beta 1 release it’s actually quite good. Except QuickAccess’s crash (which is a unmaintained 3rd party applet), I didn’t encounter any crashes. I’ve seen final software releases do worse than that. 😉
Nokia and KDE still have quite some time to fix Qt 4.7 and SC 4.5 before their final releases. SC 4.5 comes out in August (don’t know about Qt 4.7).
As far as I know, it is not a Canonical contribution. The systray over dbus design has been made by KDE folks in Q4 2010/Q1 2009… See Aaron Seigo blog for more info…
http://aseigo.blogspot.com/2009/04/system-trays.html
Edited 2010-06-07 11:05 UTC
You’re confusing two thing. Icons via dbus is a KDE design.
I was explicitly writing menus via dbus and that’s by Canonical: http://people.canonical.com/~agateau/dbusmenu/index.html
I’m not to keen on the whole monoscrome systray thing. I can certainly understand that some people may like it, but i did prefer the old colorful notification icons, especially as kde always did seem to frame the notification area correctly and put proper spacing between the icons. So esthetically, i personally see no benefit to the new look.
If one had the choice for monochrome vs full color, that’d be nice. Tell me, is this a feature of the icon theme, like it is in gnome, or is it “hardcoded”?
You’re right. I was confused by that, too. While I have nothing against monochrome icons, when I used SC 4.5, there was that weird mix of colorful and monochome icons. That mix looked out of place.
uhm, it’s white icons on dark background, looks fine here (in the future there could be a different systray theme for oxygen but seems to work quite nicely so far).
however there was a bug in the rendering of the background of the systray that i think has slipped into beta1, should be fixed by now
KDE SC 4.5 doesn’t depend on Qt 4.7
doesn’t seem to happen here, make sure developers are informed tough
iirc should have already been fixed post beta1
yeah noticed it as well, but again, at the moment the best Qt release to run 4.5 is Qt 4.6.3
The frame of the systray looked weird.
Don’t know if that’s the background bug.
Yeah, I know, but I had hoped that the Qt 4.7 version in openSUSE’s repo already had the icon patch.
Hard to inform any developers if I don’t even know which component is responsible? Qt 4.7 (=Nokia)? GPU drivers (=NVidia)? XServer (=Xorg)? Plasma (=KDE)?
I’m using openSUSE 11.2. Maybe a component that already has a newer version without that bug is already out. I’ll test it again once I have a Live CD with more recent components (incl SC 4.5) at hand.
Check out the included videos.
I am now beginning to find the activity browser a lot more useful. I think KDE should do away with the multiple desktop metaphor and move to a multiple activities for each “desktop”, at least in its default configuration.
Multiple activies are easy to grasp by users. What was lacking was the actual implementation which had remained buggy and not ergonomical enough. But the new one in KDE SC 4.5 looks very promising.
After more than 12 years, I am currently Gnome because it worked better than Mandriva on my netbook, but I can´t wait to go back to KDE. Even though Gnome works fine, I miss many of KDE´s features and find myself a little more productive in it, but I have gotten to respect and like the vision for Gnome. It really has come into its own, which is not something I could have said with a straight face a few years ago.
It feels very liberating to have two such prominent desktops and to be able to switch back and forth between them to try new things and learn new ways of doing things.
I’ve been using a bit everything, like many. However I kinda like the comfort of gnome & kde, full featured desktops.
Still, I always find myself in a situation where i’m coding stuff and i just wanna go back to fluxbox, or whatever your light manager of choice is.
Main reason is tiling. You want to see your browser and 2 or 3 terminals for example, at the same time. Not on a virtual desktop where its hidden. Not shaded etc. Just see it all.
You’ve to spend quite some time organizing the windows then, and on a laptop and with a trackpad it gets annoying over time. With automatic tiling, you don’t need to.Most lightweight window manager do that too. And it’s in KDE 4.5
I’ve tried KDE 4.4.? with an NVidia and an ATI card and KWin feels so slugish on both. If I use compiz everything is smooth, Was this an specific problem of 4.4 that is fixed in 4.5?
At least on my desktops/workstation KDE 4.4 kwin seems fast enough. (Desktops rand from AthlonX2 4200 to dual Xeon L5530)
I did switch to my Asus 1201N to GNOME, but this had less to do with CPU usage and more to do with saving memory to be used by VirtualBox. (KDE + kwin effects eat >100MB more than GNOME + metacity, and I needed every single byte…)
FWIW I’m using Fedora 12 and 13. All x86_64.
– Gilboa
Same here, Intel graphics. KDEmod 4.3 was smooth, 4.4 is noticeably slower.
Why was this modded down? It’s not offtopic, it isn’t incorrect, and it isn’t trolling.
For me also, KDE 4.3 was much smoother than 4.4.
That’s something I’ve never understood, even on theDot, admins. have deleted comments regarding errors in KDE, looks like they can’t handle the criticts, even the contructive ones.
Edited 2010-06-07 23:56 UTC
As KWin gains new features, it occasionally triggers bugs in the drivers.
It’s not KDE’s job to work around bugs in the drivers, it’s the driver vendor’s job to fix its drivers.
An alternative explanation could be that you manually set the compositing render mode from OpenGL to XRender. Check System Settings.
I could agree with you, but when the problem is with Intel, NVidia and Ati, and compiz works well, I don’t think the problem has to do with drivers.
Have you compared the sources of KWin and Compiz to check whether both use the same principles to achieve similar looking effects?
I didn’t and I guess you didn’t, too.
Here’s a play of thought:
Let’s say Compiz uses OpenGL 1.3 for its effects and KWin uses OpenGL 2.1.
Both Compiz and KWin could be bug-free, but some driver handles OpenGL 1.3 better than OpenGL 2.1.
Of course, I don’t know which is the actual reason for the performance discrepancies, however judging by past experience, drivers are likely to blame.
For NVidia GPUs, drivers older than v180 caused many problems with Qt4 and KWin. It was so bad, I installed a beta of v180 that regularly caused X to crash, but the way better performance weighted more.
Since then (1.5 or 2 or so years ago) Qt4, KWin, and Plasma is a smooth experience for me (GeForce 9200M).
I’ve read similar stories about the proprietary ATI drivers. I suggest to try recent FOSS ATI drivers that are reported to work well with window managers.
Intel had its fair share of problems as well when the internal driver architecture was changed. It caused performance regressions in all sort of areas.
If OpenGL 2.1 than causes problems with almost all drivers, be it the drivers fault or not, maybe the Kde team should consider switching to OpenGL 1.3.
Please read my comment properly. I didn’t say that it was actually OpenGL 2.1 or 1.3.
It was just a play of thought why performance differences could possibly occur.
Additionally, your reasoning is completely wrong. NVidia, ATI, and Intel have billions of dollars. They can easily fix their drivers if they are broken (NVidia’s drivers are already fixed — at least for GForce 9200, btw.)
KDE is merely a community project — with some corporate sponsors, but much less resources nonetheless.
Edited 2010-06-08 16:18 UTC
Im not using ATI’s propietary drivers, so that’s not the problem, is anyone in the KWin world even investigating these problems?
I don’t know, but considering that there’s no fund raiser for graphics cards for KWin devs, I don’t know how you’d even expect voluntary community workers to investigate this.
AFAIK the last person to be paid on KWin was SUSE’s Lubos Lunak who — while still being involve in KDE — now does other things for his employer (Novell/SUSE), like the KDE Desktop integration helper app for Firefox.
Community FOSS contributors already do work for free. It would be very rude to expect from them that in addition to their voluntary work, they also buy all sorts of graphics cards to investigate a problem that’s likely not even caused by them.
This shows once again why it’s the GPU manufacturer’s responsibility to do that work. They do the driver programming already. They have all sorts of their own GPU models at hand for free.
So if current drivers did not fix the problem, try different ones: The proprietary ATI drivers (on the Radeon) and Nouveau 3D for NVidia hardware. If one of the drivers does not have the problem and the driver is the only component that has changed, the result is pretty clear: Faulty driver. Report the bug for it.
Then it could also be the fault of Xorg. Try different versions of it: The newest and an older one. Problem only on one version: Report an Xorg bug.
If the performance regression persists through all setups, only then you can be sure it’s a KWin bug.
Yeah, it’s a lot of testing. But think of it: If you are expecting the voluntary KWin devs to “investigate” this, be aware that the devs have to do all the steps as well — for all sorts of graphics cards they need to buy themselves.
Btw, if you have — at least to some degree — found out the cause for your regressions, try to reproduce it with openSUSE and Fedora and report the bug on the bug trackers of Novell and Red Hat (in addition to the upstream bug tracker). Unlike Canonical or some hobby distributor, Novell and Red Hat have capable developers who may be able to fix it.
No thx, I want a functional desktop, not a drama story about developers. So, I’ll stick with compiz.
Now that’s a “great” attitude…
First you bitch about allegedly “broken” features, then you aren’t willing to do proper bug triaging on a community FOSS product, and then you bitch again about “drama stories” as if the KWin devs owed you anything.
If you want full-blown commercial-grade support, go ahead and pay for it.
If you don’t want to pay for a support contract, don’t whine and keep quiet instead.
kde has all the capability in the world. but in 2010 kde and its distros are still science projects.
by the time someone turns this into a good product we might not need it.