KDE Commit-Digest for 23rd July 2006

In this week's KDE Commit-Digest: KDevelop gets new configuration framework functionality. The start of a Satellite tracks feature in KStars. Support for PDF data extraction, and speed optimisations in Strigi. New features in KPhotoAlbum (KPhotoAlbum is the new name for KimDaBa). Perspective grid support in Krita, with the implementation of a Bezier tool becoming feature-complete. More work on unit conversions in KRecipes. Porting of KRDC to KDE 4.


By zvonsully at Sun, 2006/07/23 - 5:00am

reads like *breakthrough* technology :-)


By ch at Mon, 2006/07/24 - 5:00am

I agree. I especially like seeing all the KHTML fixes.

Also, it's nice to see the fix for Bug 128610: kscreensaver does not launch screensaver after x minutes.

By Elijah Lofgren at Mon, 2006/07/24 - 5:00am

I for one welcome our KDE 3.5-patching overlords.

By JVz at Wed, 2006/07/26 - 5:00am

So is this basically an admission that KHTML is being dumped in favor of Webkit? More's the pity.

By anon at Mon, 2006/07/24 - 5:00am

Looks more like KHTML will (possibly) be resynced up with WebKit, which would greatly increase the number of developers working directly on the code.

By Corbin at Mon, 2006/07/24 - 5:00am

given that webkit is a khtml fork which has had a good amount of cross pollination of patches with khtml, if it does occur (there's still more work to be done before that is a for sure thing of course) it mostly means bringing a greater number of developers working on the same branch of the code.

what are you concerned might be lost in this? (your message is a bit vague on the details =)

By Aaron J. Seigo at Mon, 2006/07/24 - 5:00am

IIRC, after the apples had decided to use KHTML, the problem with webkit was that they only cared about some fubared websites being displayed correctly and added lots of quick hacks to webkit, making the code more complicated and cluttered and slowly killing KHTMLs clean design.

I have no clue of KHTML(s design), this is just what I remember. Not true?

By me at Mon, 2006/07/24 - 5:00am

it is quite true that the kde khtml devs had a higher code quality standard in certain places than the apple webkit khtml devs did. not to the point of making webkit khtml unhackable or a nightmare. and working together should help improve that while bringing more people to bear on the codebase. this should result in more bugfixes (ours and theirs), more features (ours and theirs) and more code correctness.

or it could simply lead nowhere and we maintain the khtml root branch forever. we'll see in the next 4-6 months.

By Aaron J. Seigo at Mon, 2006/07/24 - 5:00am

The question is: What breaks khtml?

Maybe I am wrong but page rendering is not really a problem anymore. I did not come across pages which broke, some rendered better. Speed is a problem but as processor power grows solved by time.

Today we have four mature engines and all work pretty well.

The problems of konqueror are usabilitywise. E.g. ugly popups. This is what annoys users, not khtml. Khtml is good enough. So if webkit results in more patches even better. I wonder why nobody tried to write a safari clone yet.

By Itchy at Tue, 2006/07/25 - 5:00am

> but page rendering is not really a problem anymore

yes, things are -very- good in khtml these days. there are still websites that bork, however (such as my hotel's gateway page last week which prevented me from getting an ip address). beyond rendering there are performance improvements and feature enhancements such as richtext editing and canvas.

> if webkit results in more patches even better

exactly the point =)

By Aaron J. Seigo at Tue, 2006/07/25 - 5:00am

They have. It's called Shiira. It's based on WebKit and Cocoa.


By Marc Driftmeyer at Fri, 2006/07/28 - 5:00am

> Speed is a problem but as processor power grows solved by time.

I don't give a **** what processor power is nowadays, I want software to run nicely on a 400Mhz.

By Nicolas at Tue, 2007/06/12 - 5:00am

> KPhotoAlbum is the new name for KimDaBa

What was so wrong with the old name that a change of capitalisation couldn't fix? I can sort-of understand changing as it's not entirely obvious, but surely you could have found something better than yet another KWhatIAmName??? I think we're all in general agreement that we're past that now, surely? It's OK for the desktop utilities that are part of the main project, but for an add-on app a little originality wouldn't go astray.

If you're going to make the effort of re-naming everything, make sure it's worth the effort. I'm sure the peanut gallery can come up with a few suggestions? In a foreign language perhaps? Heck, feel free to drop the K entirely! Maybe run a competition, winner gets their name in the 'About' dialog?


By odysseus at Mon, 2006/07/24 - 5:00am

I agree. KPhotoAlbum is a very generic KDE application name, while KimDaBA has a certain unique ring to it and sounds much more like a full-blown application. KimDaBa is easier to pronounce, to type, to remember and is not so repelling for non-KDE users. I'm usually not the one to complain about stuff like that, but that change is not a good idea, IMHO.

By Michael Jahn at Mon, 2006/07/24 - 5:00am

These "unusual" names have a big advantage: If you have trouble, just put it in google and you won't be flooded with results. Besides, strange names are easier to remember since they stand out. And hey, there funny.

By Andreas Jensen at Mon, 2006/07/24 - 5:00am

I really had my troubles with remembering Kimdarba. It's like trying to remember some names from cultures that I'm not so familiar with -- like thai city names or asian dishes. So with respect to this I disagree.

Apart from that: People complained before the name change. There was a chance to voice up and suggest a better name to the author. And now some people complain again. Have we really turned into a group of complainers?

I don't think this is even worth a discussion. KPhotoalbum is unique and catchy enough to appear in google without any chance to mix it up with something else. And it's immediately clear what it's meant for.

Long live KPhotoalbum!

By Monkey Boy at Mon, 2006/07/24 - 5:00am

Well, I took the chance and suggested to stay at KimDaBa but I was overruled. This is ok with me, majority decides. But KPhotoAlbum may be unique, but searches get more fuzzy and may left the leading K out, since this makes it a regular word, and voila you're in trouble.

By Andreas Jensen at Mon, 2006/07/24 - 5:00am


I read about the future release plan of KDE3.5.4 it says tagged on 23-07-06, but where is the plan for further release of KDE3.5 please don't tell me that 3.5.4 is the last release

I really love my kde3.5

By morphado at Mon, 2006/07/24 - 5:00am

If you love 3.5, then keep using it! You don't have to stop using it just because no further releases are planned.

By LMCBoy at Mon, 2006/07/24 - 5:00am

That's was really a funny answer.

By Ignacio Monge at Mon, 2006/07/24 - 5:00am

I think people should care about the long lag between 3.5.4 and upcoming release of kde4,specially when most distribution who care about stability will wait till kde4 become really stable let says at last kde4.0.1

Gnome people should be really happy

By MORPHADO at Tue, 2006/07/25 - 5:00am

It happened before: people were stuck on KDE 1.1.1 for _ages_ before KDE 2.0 came out, and it didn't have too much of an effect. Some people moved over to Gnome which had gained theming support, but they moved back to KDE when it came out. I imagine the same will happen once more, although I'm just moving _back_ from Ubuntu to Debian Sarge running KDE, as that is the system that works for me.

As for distributions waiting for stability, that's a bit of a joke: the only distributions that wait are Debian and the enterprise desktops (RHEL, SLED). Pretty much everyone else (Fedora, OpenSuSE, *Ubuntu) jumps right in at the earliest opportunity. I wouldn't be surprised if there were some installable live-CDs floating around with KDE 4-beta when it ships.

By Bryan Feeney at Tue, 2006/07/25 - 5:00am

I clicked the _Diff_ link to read the flake-overview, and http://websvn.kde.org/trunk/koffice/libs/flake/flake-overview?r1=564922&... displayed "ViewCVS Exception Invalid path(s) or revision(s) passed to diff"

The r1 revision number is bogus. This may be happening because it's a new file, not a change. The exception also happens when I click the _Diff_ link for other new files, e.g. new Arev font
I'm not sure how to get ViewCVS's diff mode to do the right thing for a new file.

It would be nifty if the commit-digest could tell it's a new file so instead of saying "Thomas Zander committed a change to /trunk/koffice/libs/flake/flake-overview: ... _Diff_" it said "commited new file(s) ... _View_" with a link to View instead of Diff.

I really appreciate these summaries!

By S Page at Tue, 2006/07/25 - 5:00am