The KDE Project announced
KDE 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.
Dot Categories:
Comments
Here it's 19 !!!
sorry but Kmldonkey, Kgpg and k3b are not native kde apps. so that brings it down to 16 :-p
You do not seem to be running 3.2/cvs
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.)
For what it's worth I disagree quite strongly with the removal of "View Document Source" from the context menu.
However, since there are people who are actually defending this action (yes, I'm looking at YOU aseigo ;) you can fix it locally by downloading this file from my site:
http://c133.org/files/khtml_popupmenu.rc
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?
> That goes to Stephan Binner. Complaints about this will not be very visible here on the dot
This can IMO be read like that I would delete comments I don't like. This is not the case.
> why not send an email to binner @ kde.org to let him know that you use 'View document source' in your context menu?
Campaigning instead of arguments will not help.
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!
If you want to permit root logins by anybody through KDM, sure. Here, I think we'll update since our configuration is definately vulnerable. I'd suggest you at least read the advisory...
That godawful-irritating horizontal scrollbar bug (http://bugs.kde.org/show_bug.cgi?id=61730) was also fixed, though it didn't get a mention in the changelog.
Sooo happy!
That was fixed in 3.1.3a or somesuch. Look here:
http://www.kde.org/info/3.1.3.php
It _is_ mentioned in the changelog. Look harder... (OK, it took me some time to find it too) :-)
One thing I do wish is that the tabs in Konqueror would stop changing size all the time. It seems to be a bit worse in 3.2 than 3.1 because even the main tab changes size.
Posting feature requests here is pretty useless. I'd submit wishlist items to bugs.kde.org instead (just make sure it's not already been wished for).
bugs.kde.org is a pretty useless place for open, public discussion. Some would rather wait and discuss than rashly dump a slew of undiscussed comments into bugs.kde.org.
take care,
j
>bugs.kde.org is a pretty useless place for open, public discussion.
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...
There's a patch for that in qt-copy/patches ..
(still doesn't work like it should though, but it's a bit better)
The OP is not talking about flicker.
I'm not talking about the flicker either.
So you're talking about a patch against Qt to fix/revert a "tab size problem" implemented as feature in Konqueror code? Now, that makes sense ;-)...
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.
Teddy
Unfortunatly, there is too few people working on docs. The good news is that it requires very little technical skill to contribute! Hope that if you have time, you'll contribute :-)
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 :)
prelinking....
i like that word!
how do you do it, what does it do and is there really much performance gain.
Have a look at this document:
http://www.gentoo.org/doc/en/prelink-howto.xml
It's intended for Gentoo, but other than the instructions on how to install the Prelink package itself, everything else applies.
Personally, I did it, but didn't notice much gain. And then I realised that I had wasted 30 minutes setting it all up, when I really don't mind waiting a couple of seconds for KMail to apear ;-)
Why can't prelinking be used in combination with NVIDIA drivers?
Because the NVIDIA binary drivers (specifically, the libgl) are compiled in a way that makes it impossible to prelink anything that links with them. This includes Qt, which links to them for QtGL.
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.
yep, and their is a lot of "WARNING !!" and "BEWARE !!" thingys on their site. and perhaps even more importend: objprelink2 does not currently work with gcc-3.x.
so i guess it won't be really that usefull right now.
this is actually the prelinking tool:
http://freshmeat.net/projects/prelink/
objprelink is deprecated
Ok, but the paper states:
The runtime linking time now represents only a small part of the KDE3 application startup time. Large speedups are to be found elsewhere.
How much more time can you shave off with the new tool?
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.
Did you remember to flush your memory so that the app was not cached when you ran your second test? I doubt its really that glamorous...
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.
Does anybody know whether the bug 53735 (menu extensions, i.e. kasbar don't have transparent background) has been fixed?
This annoying thing comes up in every version since 3.1.1 -:(
regards
rainald
If it's not marked as fixed on bugs.kde.org, then it isn't.
It's not fixed. I wrote a new rendering system for kasbar that fixes this, but I still haven't had a chance to merge it into the CVS.
Rich.
You will have at least one admirer for this ):-
I tried to find out the reason for this bug for myself, but I didn't had success yet -(:
regards
rainald
I really hope you do.. I used to use kasbar a long time ago (kde 2.1??), and I loved it. I had to stop using it because of the above mentioned problem. :(
Hope you find time to merge it! (and if not, get someone else to, *snicker*)
The oldest unassigned bug in konqueror -- reported almost three years ago: http://bugs.kde.org/show_bug.cgi?id=12994
More missing CSS:
http://bugs.kde.org/show_bug.cgi?id=26326 (note that this is CSS1 -- without support for this basic property Konq's claim to support 100% of CSS1 is incorrect)
Pathetic handling of PNGs (frequently valid images are inverted or even blank):
http://bugs.kde.org/show_bug.cgi?id=16395 (note that this has been around since before KDE 2.0!)
http://bugs.kde.org/old-bugs-statistics.cgi?tops=15&ids=20912 -- konqueror still has 13 bugs that were reported before KDE 2.1, and 45 from before KDE 2.2.
Let us know when you've fixed them, then.
'So fix them, then' is a sneering, pointless answer. Try again, using your brain this time.
That's because it was an answer to a pointless, sneering question.
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.
Our demands are less than or equal to the overriding praise and publicity that KDE e.V. and friends spew forth about its greatness.
And this is a rational statement, intended to persuade people to fix some of those bugs?
> http://bugs.kde.org/show_bug.cgi?id=16395
Can't be fixed until qt 4.0
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.
Here's what I want:
- 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.
"It really doesn't make sense releasing software with thousands of bugs"
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.
"Sir, your last statement contradicts itself."
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!