In this week's KDE Commit-Digest: More work on runners, bindings into WebKit, and the beginnings of better composite manager support in Plasma, with support for multiple feed sources in the RSS Plasmoid. The addition of a "BBall", "Show Desktop", "KMLDonkey", and "IM Presence" (using Decibel) Plasma applets. An alternative alt+tab window switcher (similar to Compiz Fusion's "Cover Switch" effect). SuperKaramba gets support for Qt 4.4 "widgets-on-canvas". A long-overdue "major" rewrite of KCron is undertaken. Undo support in the KShortcutsEditor dialog. New plugins in Digikam and Krita. Various improvements in KTorrent and Amarok 2.0. Interface work and MusicBrainz integration in KsCD (student project). Lots of work on page transition effects in KPresenter. The start of work on integrating online reader support into Akregator. Kubrick, a Rubik's Cube game, is imported into playground/games. KDiamond moves from playground/games to kdereview, Kollision from kdereview to kdegames for KDE 4.1. kdebase (trunk, KDE 4.1) now requires Qt 4.4. Akonalendar (a small app to demonstrate Akonadi KCal models), and the Quasar graphics library are imported into KDE SVN. Read the rest of the Digest here.
Comments
> "Show desktop" icon: Takes seconds
that's because we're creating a full screen widget to do this with. there are no x11 wm hints to do what we want properly yet, so we have to do it all manually. we delay the cost to the first time you hit the button rather than at start up, to keep start up fast. once we have the needed wm hints, i hope this can be sped up somewhat.
> "Settings": .kde4-directory has to be erased every couple of days
ugh. it would be great if you could try and pinpoint what it is in there that causes the problems so we can fix it. deleting the whole thing doesn't help much. perhaps try moving it aside, adding half the files in share/config/ back and restarting the desktop .. and do a binary search from there to find the culprit.
the rest definitely sounds like graphics driver issues.
>> "Show desktop" icon: Takes seconds
> that's because we're creating a full screen widget to do this with.
Hm. Whatever the reason for this, it doesn't seem to be the best solution ;). Concerning the desktop icons, I BTW cannot resist the feeling that KDE4 is in many aspects taking a somehow awkward approach (e.g. the way ~/Desktop is handled), but I also know that "desktop icons" have been quite a controversial issue ;))).
> ugh. it would be great if you could try and pinpoint what it is in there
> that causes the problems so we can fix it. deleting the whole thing
> doesn't help much.
Well, most of the time deleting only "plasmarc" does the job, too. However, this might also be an openSUSE (development version) related thing. After all, I seem te be not the only one experiencing this.
It's also very hard to pinpoint - it works a few days, and then one day I try to start and the whole desktop stays blank. As there are openSUSE updates in beteween, too, you cannot really say what was the reason. It's pretty annoying nevertheless, and no programm should IMHO crash because of problems parsing a config file.
> the rest definitely sounds like graphics driver issues.
Possibly. The frustrating thing is that anything else (compiz, KDE3 compositing effects, 3D and so an) works flawless on this computer :(. What makes KDE4 so different (for me and lots of other users)?
from what i know, there is a severe bug in the nvidia binary drivers.
QT 4.4 uses a special function in that driver, that nobody else realy uses. and it uses it very often. This means, only kde 4 is affected by that nvidia bug. Lets hope it gets fixed soon.
that rare function is, afaik, most of XRENDER functionality - which really sucks in NVidia binary.
Hm. Aren't the effects done by OpenGL and not by XRENDER?
> What makes KDE4 so different (for me and lots of other users)?
it's brand new ;-)
Seriously, that's it. There are many issues in underlying technologies (Qt, X.org, drivers) and in KDE itself which KDE 4.0 is supposed to expose - and as you can see, it does. This bites users, sure, but thanks to this exposure we can expect KDE 4.1 to be much more stable and predictable.
Of course, users helping to fix the issues is important to KDE: if you could find the issue for the plasmarc breakage, for example, that would be really great.
Well put. That's why we pay you the big bucks. ;)
Have to agree with the speed. Though not of this kind, MS Vista seems to be rocket fast compared with KDE 4.0.1. But I am encouraged to wait for future patches.
I use 4.0.1 (latest patches) on openSuse 10.3 with latest NvIDIA driver on 8400GT.
my problems are:
o when starting a drag-action, I have to push the mouse button for a few seconds (at least too long) in order that KDE understands that a drag event is started.
o Sometimes dialogs just need ages to be drawn (for example kcontrol, kget->save-to)
o I could associate most of the speed issues with KNotify4 and plasma. In plasma, some Qt bugs (from what I have learned) yield 100%cpu usage (for a few plasmoids). For KNotify4 - well - this is a really dangerous software! On my box, it almost runs all the time. Just switch windows and desktops for several time and KNotify wakes up to run and run... at least 80% cpu usage even when the system is idle. The same goes for system sounds: The first time KNotify4 plays a system sound, the complete desktop freezes for a minute... I already filed a bug report, please vote for it!
Currently the nvidia driver is broken in regards to kde4. the only solution as a nvidia user right now is NOT to use kde4 and wait for a corrected version of the driver (which could take anything between 2 months and 1 year).
I'm afraid your sample size of 1 is invalid, for me everything is working fine (nvidia+opensuse10.3+kde4.0.*). Undoubtedly there seem to issues for some users but such a sweeping statement is uncalled for and inaccurate.
His sample size is more than one; I've read multiple complaints on the Planet. I've got the same problem myself. You are only the 2nd person I've heard of who has an nvidia card that works fine with KDE 4.0. Consider yourself lucky!
> You are only the 2nd person I've heard of who has an nvidia card that works fine with KDE 4.0
Oh, then you are probably working at the nvidia-helpcenter? :) Well, I did run KDE4 so far on multiple configurations with nvidia's and never had a problem there. So, probably the "multiple complaints on the Planet" don't reflect most ppl?!
What nVidia cards are we talking about here?
OpenSUSE 10.3 says that I don't have a 3d card at all,
but Mandriva greets me with a big fat nVidia logo and works
like a charm. (GeForce FX 5600)
Probably a dumb question, but: Do you have the NVidia drivers installed? (Look at en.opensuse.org/Nvidia for details.)
eeh.... no.
Too lazy, I'll stick with Mandriva.
Just to correct all previous posters to my comment:
The NVIDIA issue is only one thing - it indeed feels slower, but not in a way that KDE4 is unusable. My impression is that compositing is just not optimized yet.
My impression is that other things like KNotify4 and the Oxygen style urgently need stablization/optimization.
Unfortunately I have to agree.
It is kind of slow. I'm sure you guys will figure out how to bring all of the above up to speed by KDE 4.1. I have faith in you.
I don't seem to be affected by these strange problems using KDE 4.0.2 w/ openSuSE 10.3.
Well I could say that I guess ATI FGLRX proprietary drivers are not so bad after all ;) however this I know not to be the case lol. For desktop KDE 4 usage however, sounds as if FGLRX screams (fast) in comparison to NVidia drivers...
Just go tell NVidia on their forums that ATI FGLRX is faster at KDE 4. I GUARANTEE YOU that if you do this (and report a bug to their driver team about it with very specific test conditions and system setup, with benchmark comparisons), if you do that they will have it fixed in 30 to 90 days.
FYI, when I used a GF 5900 Ultra and reported 12 bugs in one session (using the aforementioned criteria) it was fixed in 14 days. TWELVE BUGS IN TWO WEEKS SQUASHED. While I do not believe I was the only person reporting all of those bugs, I do know for a fact that atleast 4 of them (which affected a vast number of applications) my information/instructions helped to reproduce the bugs in their labs.
If you do not report a bug "properly", then do not expect it to ever get fixed...
Regards,
got root
Will it be ready for kde4.1 ?
Well yes, it's actually part of Qt 4.4.
That doesn't mean that WebKit can be used by Konqueror. I hope it will be done (at least optionally).
There's been some activity here by mr Wolfer :
http://websvn.kde.org/trunk/playground/libs/webkitkde/?sortby=date
So maybe...
Yes, you can compile the Webkit-KPart. It's working mostly, you can e.g. change Konqueror from KHtml to Webkit...
Lukas
Nor does that mean it will be done well.
Cool. KDE 4.1 will be an exiting release.
Aaron Seigo, please make another keynote video when it is ready to be shipped. It helps users a lot, at the same time it creates buzz for the KDE project.
I'm not sure I like this. From a architectural viewpoint, I think this is not the way to go. For apps like this, a separate "engine" should be made, wich can run as a daemon on a server. Then, one can choose a client to communicate with the server: a KDE/QT client, a web client, a CLI, etc. For a single machine setup, the daemon runs on the local machine. One could even accept multiple deamons. Look at the way MLdonkey does it. That's the correct approach. Same thing for Amarok: Create a amarok "engine" that run's as a daemon on a server, then use Amarok (the KDE app) for communicating with it. Next, a web client, a CLI, etc could be made. I'm sure more apps could be architected this way. Use open standard for the communications where available. Another app that comes to mind is Ktorrent.
Just my $0.02
Bah. I still have yet to see an app like that that makes any sense for most users. This design adds another layer of failure potential, and a UI that most users shouldn't care about. I remember mldonkey or a similar app, and you had to start some server in the background, and half the time it would work, and half the time it wouldn't. Then that server wants to run as a daemon, but really I dont care about that, and I only want it to be running when I start the app.
99% of amarok/kget/ktorrent users will only use it on the local machine. So the server architecture only brings downsides for them (reliability, memory consumption, ui complexity).
http://techbase.kde.org/index.php?title=Projects/Summer_of_Code/2008
Please provide more submissions to Google Summer of Code projects.
Please also tell all your friends about GSoC, both mentors and students that would like to make extra cash in the summer.
Maybe we could have a separate dot topic for this, so more people notice. (just a suggestion)
http://techbase.kde.org/index.php?title=Projects/Summer_of_Code/2008/Ideas
The specific thread. :)
Will there be any new Desktop effects for Kwin at this years GSoC?
I looked at the site, and there don't seem to be any projects submitted under Kwin. Are they under a different heading, or am I just not looking in the right place?
I mean compositioning effects.
Those are not project submissions but a list of ideas what could be used as a SoC project.
These are mainly things that we think would be useful but haven't time for ourselves or are specifically interesting for new developers (e.g. don't require much internal knowledge)
All students interested in doing a SoC project with KDE are encouraged to think of something interesting themselves and apply with that idea.
That might not only be more interesting the stuff we thought about, but also introduces new views and new use cases.
Oh Cool....
Could you put Compositioning effects on there as a cool idea though? That would be great.
Hey there. I've been building KDE4 from trunk since it produced anything clickable on the desktop. I updated almost every second day and watching your progress was really fun. Lately I've been on a trip for about a week and was away from my PC. Rebuilding took a while longer but it is absolutely wicked what can change in just one week of absence.
I've never been this deep into a live development process - sometimes it makes me think I've become the wrong type of engineer ;-)
Keep up the great work!
CU and greets form Germany
danielHL