The KDE Project announcedKDE 3.1.4 today. It's the fourth maintenance release of the successful KDE 3.1.x series and
ships with many bugfixes and improved translations. KDE 3.1.4 also contains two fixes for security issues in KDM. Users of KDE 3.x are advised to upgrade to KDE 3.1.4. Read the incomplete change log or jump directly to the
download links on the KDE 3.1.4 Info Page. The Konstruct build toolset was updated accordingly.

When clicking on blank spots in html pages, Up has been removed, "Open in New Window/Open in background tab/Open in New tab" have been replaced with "Duplicate in New Window/Duplicate in New Tab". "Add to bookmarks" has changed to "Bookmark this page", "Copy To" has been removed, "View Document Source" and "View Document Information" have been removed. The k3b/kgpg/kmldonkey actions, as well as Open With, are now submenus.

I'm not sure why "Stop Animations" and "Preview In" are still in the context menus in HEAD however. The latter seems inappropriate for http pages (is good for local files I guess.. perhaps move it to a submenu under "Actions" ), and the former isn't used much anymore (still is in menus for ppl who use it.)

Download it, check it out and make sure it isn't a virus or an evil shell script, and then once you're satisfied that it's just a benign config file, drop it into ~/.kde/share/apps/khtml/ and be amazed at how much cleaner your context menus are in KHTML!

-clee

PS: No, Aaron isn't responsible for this one. That goes to Stephan Binner. Complaints about this will not be very visible here on the dot, but if you want to make yourself heard, why not send an email to binner @ kde.org to let him know that you use 'View document source' in your context menu?

Completely disagreed. View source should stay in the menus, and not the context menus. If we have view source, let's put in more frequently used items than that like close window into the context menu!

That's the advantage. Most people do not want to be bothered with discussions about details, especially as long as there is no working code.

If you want to implement a significant change, post it to the appropriate mailing list before. If you have a patch, post it to the mailing list. But please do not increase the noise level for every feature request...

Yesss, but i will waiting the KDE 3.2 in this last year, and i hope KDE to be faster, couse sometime running KDE more slowly than WindowsXP in the same hardware system :(, and wish the help documentation more complete.

3.2 is very fast. KDE has been pretty fast for me for awhile now, but with the 3.2 CVS versions, its about as fast as XP. The only real performance hits are for application startup (I can't use prelinking because of the NVIDIA drivers) and redraw in applications with complex canvases (like Konqueror, though Konqui is one of the most improved apps in 3.2 :)

According to this paper: http://objprelink.sourceforge.net/ you would only get a few milliseconds better startup times compared to the combreloc method already present in the linker. Check at the bottom were Konqueror starts at 2.80 versus 2.66 seconds.

Not really. Objprelink is somethink seperate from the Jakub Jelnik's *real* prelink. Prelink does help. On my 2GHz P4, (using LD_DEBUG=statistics) starting Konsole results in a linking time of a little over 0.2 seconds. Prelinking would bring that number almost to zero. Human response time is about 0.3 seconds. So the linking step already chews up 2/3s of the time you have to make application startup appear instananeous.

Actually, when I tried prelinking the first time (a couple of months ago) it showed a 99% reduction in linking time, from about 0.4 seconds to something like 0.01 seconds. But it fubar'ed my system, so I had to reinstall. Does that count as clearing the memory? But my original point is that linking time is still significant --- it is already known that prelinking almost completely eliminates linking time.

Yes, there's a bug in there since 2000. But how likely is it that Konqueror/KHTML developers are unaware of it? Maybe if you'd asked if any progress had been made, or if people were looking at it, or whatever. But your question was more of a demand that somebody fix it.

Seriously, after KDE-3.2 is released, I think we should devote a year to squashing bugs. It will be wonderful if one of KDE's mission/objective will be to be bugless by KDE-4.0. Now, I know I'll be flamed for this proposition, but let's fix things before adding new items. It really doesn't make sense releasing software with thousands of bugs. I understand KDE is an enormous project let's be a little more paranoid about bugs. There should be a policy not to add features to a package until all/most bugs in the package are squashed. Yes, I said it. *awaits the flames*

P.S. Wishes and Requests do not count as bugs for the purpose of this rant.

- Less bugs (how obvious..)
- More solid desktop feeling (current KDE desktop doesn't feel solid - ie. flickering rubberbanding, flickering icons, ugly flickering xor-rects instead of translucent icons when dragging, flicker here, flicker there)
- More UI improvements (not just reordering the widgets or adding 20 options to each dialog)
- More professional programming API's (ie. well chosen method names, use of design patterns, namespacing, etc)
- Optimizations (use of memory, runtime speed, etc)
- Use of REAL context menus
- Death to all geek themes (Motif fluff and themes like that)
- Death to all the old pre-KDE3 icons (everything should be Crystal, more consistent)
- Death of all (or at as much as possible) ugly hacks inside kdelibs, kdecore and kicker
- Death of the many duplicated KWidgets (using QWidgets instead) which are only causing problems later on (ie. KStyle makes some Qt styles flaky (including the QtWindows style))

I'm affraid that last one won't happen, bad decision..
(even the guys at the Gtk/Gnome projects have seen the light and have started making everything use Gtk for the UI and no more Gnome specific UI fluff, except for common desktop dialogs and things like that)

Oh, and I want lots of $$$ and make a trip to Mars.
But I'm affraid that won't happen either.

Yes it does. Or are you saying that past KDE-releases were pointless and/or senseless? You would rather have KDE-team polish up KDE1, instead of releasing KDE2 and KDE3? Because that is what would have happened. Right now we might be running KDE 2.0, but it would be relatively (since you can't really eliminate all bugs) bug-free. Is that what you would want?

Even if KDE was released 100% bug-free there would still be bugs there, they would just be unreported.

Sir, your last statement contradicts itself. And what makes you think that we would still be using KDE-2 right now if KDE-1 is bugless. Contrary to your mentality, bugs retard the development process, it doesn't spur it. Yeah, perhaps when the bugs increase to 10000 by KDE-4.0 it will begin to make more sense.

Why is that so difficult to understand? Even if KDE would be released bug free (as in: no bugs left open in database), there still might be (and surely would be) bugs in KDE which just would be discovered after release (when a lot more people would be using it).

We would be using KDE2 right now, because the rate of developement would be so slow. Since developers would focus about 98% of their time to fixing bugs, there would be very little advancement of features taking place. Therefore the rate of developement would slow down and so would the functionality of the desktop (as in, we would be using KDE2 by now, instead of KDE 3.1.4). you can't add features and rewrite the code if all your time is being taken by bug-hunting.

Also, you need to consider that it's more fun to add features than kill bugs. Your "bug-free KDE" would propably have alot less developers than current KDE does. users would notice that KDE isn't moving anywhere and they would vote with their feet and move to Gnome or some other desktop. KDE would die, but hey, at least the corpse of KDE would be bug-free!