The KDE Project has announced the release of KDE 2.2.2, a service and security release.
A fairly complete list of changes from KDE 2.2.1, released two months ago,
is availablehere.
If you are using KDE in a multi-user environment,
you are strongly encouraged to upgrade for
the security enhancements incorporated into the release. If not, you are
still encouraged to enjoy the many improvements. This may well be the last release of the KDE 2 series, given that the first
stable KDE 3 release isscheduled
in about 3 months. Happy Thanksgiving!

Got it! Running 2.2.2 as we speak :)! I have already found few annoying bugs that have been squashed with this latest release (like moving/copying multiple files in Konqueror. It used to give me problems before, but not anymore :)! And Konqueror seems a bit smoother when in filemanagement-profile than before. But it could be that I'm just seeing things.

All in all, an excellent release, as usual :)! Now if only you could fix the one thing that annoys me... Meaning the multicolumn-view in Konqueror. I just can't make it look nice. In Windows (Boo! Hiss!) it looks nice, because it shows entire filename without cutting it to several lines. If I remove word-wrap, Konqueror shows only part on the filename. In Windows (yeah, I know), it adjusts the horizontal distance of the files according to the longest filename. There already is a wishlist-item on this matter. That is the ONLY onnoying thing that I can think of right now. Speed is OK, but of course, more wouldn't hurt ;)

Exactly what rpm packages need to be downloaded and from where? Plus in what order do they need to be installed? Thanks for any help. I have only fresh installed Red Hat releases in the past, never upgrading anything due to not knowing how.

Usually, you don't have to worry about which comes first. If you get all the packages just run 'rpm -Uvh *.rpm' the sequence is automated, it will install kdelibs, arts, kdebase ...

a good approach is to install kdelibs first, check which 'blahblah.so.blah3' is missing, use 'rpm:blahblah.so.blah3' in konqueror to get to know the package from http://rpmfind.net. It would be easy for anybody to search the package by mere library or an executable file from rpmfind.net. like you want 'kmines' game but you don't know where or in which package it is present, just do a 'rpm:kmines' or visit rpmfind.net and search with the keyword 'kmines' or any library file like xxx.so.3 or gohome.png.

Ben made packages for Redhat 7.2 that uses Ksplash/ML instead of normal ksplash and have some fixed from cvs posted after 2.2.2, have objprelink, etc.
For me those rpms are much better than the redhat official ones.

Hard to believe, that Bero's packages aren't build with objprelink, since 2.2.2 is launching faster than Redhat-7.2 Gnome now.
Overall performance is from acceptable to great, maybe some gcc-RH improvements here?!

Bero has been commenting to the story on slashdot about KDE2.2.2 - he (and other RH guys) arent keen on objprelink as its a KDE-only hack - 'prelink' is preferred, which can prelink most ELF binaries or so I'm told.

(but yes, the RH 7.2 RPMs were built with an updated GCC - possibly with some compiler updates/optimisation from Jakob @ RedHat as well [this info also from bero's comments on slashdot].

Speaking for myself and probably some more: I tried Konqueror and quickly came to the conclusion that javascript support sucked, which made me go back to Galeon.

You know what? Javascript was turned off. It never crossed my mind that javascript would be disabled by default. The option to turn javascript off should of course be there and people expect that there's a way to turn it *off*. But to have javascript disabled by default really seems like over protection. Trust me, nobody will blame Konqueror for being unsafe just because it has Javascript turned on and someone visitied a malicious js site. The issue is on another level. Javascript is not a banned language or something, it's used for a lot of good things.

How the hell did you find out THIS Bug? It looks like an easter-egg-like bug. Perhaps there is another bug which comes up if you press Ctrl-Alt-NumLock, open the CD-ROM twice and ping the network-interface once after you click in the left-upper corner on your KDE-screen *g*

SCNR
Pietz

BTW: I also hope that this Ctrl-Tab-Moude-Hammer-Bug disappears in KDE-3

I noticed a lot of quirkyness with KDE 2.2.1 in terms of random crashes after a certain mouse click. Hopefully this will improve with 2.2.2.

Infact, after crash #8 (note they didn't occur all the time for me but enough to be substantially annoying), i was so angered I simply removed 2.2.1 from my machine. I'm tired of being without the ease of use KDE offers so I'm giving 2.2.2 a good try.

I really like KDE -- I just hope stability becomes the number one concern. I used GNOME for quite awhile because despite it's many shortcomings rarely did GNOME/sawfish take the session down (and no, I didn't try or want to try Nautilus.) Features/bells/whistles won't mean a damn thing if the core is dumped.

I used to have a similar problem. When I pasted text (url for example) many times system just seemed to freeze for a while. I eventually tracked the problem down to klipper. I just killed it and everything has worked flawlessly ever since. But to my knowledge I have been running Qt-2.3.1 (running Debian testing/unstable). Haven't tried with KDE 2.2.2 yet.

Because having QT 3 on your box in no way affects KDE 2.x's performance, it still uses qt-2.x.x. I hope. It *really* shouldn't work otherwise (or else the people working on KDE 3 are gonna be seriously pissed off ;-)

The FreeBSD binaries of KDE are the responsibility of the FreeBSD project. You can either install via ports, or using a precompiled package. I fully expect that 2.2.2 packages will be made available for FreeBSD soon. As of right now they aren't available, but give it a week. Currently 2.2.1 is running just fine.

Do I need to make some modifications to YaST Online Update settings(?), because it does not show KDE 2.2.2 as avaliable update (and I know it is avaliable). Or do I need
to download each rpm and install them via package manager?

I'm not sure quite how viable diffs will be for 2.2.2 - 3.0. (More viable than 1.x - 2.x due to the nature of the changes though). Rest assured though that if they are viable, I'll make them and put them up in the same place.

just to let you know, the kdelibs-2.2.1-2.2.2 diff threw an error back at me with one of the files (sorry, i forgot which one). i remember looking at what didnt get patched, and it didnt look too important, it was an error function or somethign... sorry i cant provide more info... just have a wee check of the diff. i already had the kdelib-2.2.2 downloaded anyway by that stage.

I wonder if it will be possible to implement the following cut&paste scheme in future KDE releases:

1. Enable selection with middle mouse button
2. If selection was made by holding middle mouse button coppy the selected text into the clipboard
3. If selection was made by left mouse button nothing should happen to the contest of the clipboard
4. When middle mouse button is peressed and released the contents of the clipboard should be coppied in to the place where the cursor is, or if something is selected the contents of the clipboard should replace that (i.e. "paste over").

No, your idea (though creative) goes in the bit-bucket for now :-) KDE runs on X windows; even though we could be deliberately different than every other app there, we wouldn't want to be without a _very_ good reason. It takes a lot to justify that degree of confusion, and I don't think X11's behavior is bad (in fact, it's one of my favorites when done right).

However, I'll certainly admit kde2's handling of the clipboard is pretty broken by any standard. The flak it has drawn is well-deserved; unfortunately, most of the complaints show up as people wanting to do away with copy-on-select :-(. Thankfully, qt3 (and thus kde3) do do much better in this regard, since they finally follow the X11 spec for clipboard behavior fully. It now works as follows... hopefully this satisfies almost everyone :-)

It works now. Trust me. You can paste over selections, etc, the behavior should be what you expect if you come from anywhere except kde2 :-) Even then, the only behaviors that should have changed are the ones y'all hate.

GNOME apps are also reasonably compliant if you want to play with the new behavior and don't have time to try kde3. Not all of them have both kinds of copy implemented, but those that do for the most part get it right (I'm not aware of any exceptions).

selection and clipboard no longer interfere - middle-click is 'quick paste' and duplicates the contents of the selection (as in kde2.2); copy/paste have no effect on this. The clipboard used by Paste changes only on explicit Copy and is not directly affected by the selection.

Basically, if you only use one style or the other (select->middle button vs. control-C/control-V or similar), it should do what you'd expect, only people that currently use control-V expecting to get the selection (or vice-versa, middle-click to get the clipboard *after* clearing/changing the selection) have anything new to learn. If you are one of those people, read on :-)

The selection is now stored distinct from the clipboard. The selection changes whenever the user selects something (hey, how sane is that). The clipboard does _not_ change when the selection does; only explicit copy (control-C, menuitem, whatever) will changes the clipboard. Copy replaces the current contents of the clipboard with the current contents of the selection (ie, copies the selection to the clipboard).

There are (will be) two kinds of paste, which I will call (for lack of better names) quick-paste and clipboard-paste. quick-paste (X11 stype: shift-insert, middle button) pastes the contents of the selection, regardless of the contents of the clipboard. Clipboard-paste (control-v, menuitem, toolbar, etc) paste the contents of the clipboard, regardless of the contents of the selection (recall that the clipboard does not change on selection).

And there was great peace and harmony among users of the clipboard (I hope) :-).

No, your idea (though creative) goes in the bit-bucket for now :-) KDE runs on X windows; even though we could be deliberately different than every other app there, we wouldn't want to be without a _very_ good reason. It takes a lot to justify that degree of confusion, and I don't think X11's behavior is bad (in fact, it's one of my favorites when done right).

However, I'll certainly admit kde2's handling of the clipboard is pretty broken by any standard. The flak it has drawn is well-deserved; unfortunately, most of the complaints show up as people wanting to do away with copy-on-select :-(. Thankfully, qt3 (and thus kde3) do do much better in this regard, since they finally follow the X11 spec for clipboard behavior fully. It now works as follows... hopefully this satisfies almost everyone :-)

It works now. Trust me. You can paste over selections, etc, the behavior should be what you expect if you come from anywhere except kde2 :-) Even then, the only behaviors that should have changed are the ones y'all hate.

GNOME apps are also reasonably compliant if you want to play with the new behavior and don't have time to try kde3. Not all of them have both kinds of copy implemented, but those that do for the most part get it right (I'm not aware of any exceptions).

selection and clipboard no longer interfere - middle-click is 'quick paste' and duplicates the contents of the selection (as in kde2.2); copy/paste have no effect on this. The clipboard used by Paste changes only on explicit Copy and is not directly affected by the selection.

Basically, if you only use one style or the other (select->middle button vs. control-C/control-V or similar), it should do what you'd expect, only people that currently use control-V expecting to get the selection (or vice-versa, middle-click to get the clipboard *after* clearing/changing the selection) have anything new to learn. If you are one of those people, read on :-)

The selection is now stored distinct from the clipboard. The selection changes whenever the user selects something (hey, how sane is that). The clipboard does _not_ change when the selection does; only explicit copy (control-C, menuitem, whatever) will changes the clipboard. Copy replaces the current contents of the clipboard with the current contents of the selection (ie, copies the selection to the clipboard).

There are (will be) two kinds of paste, which I will call (for lack of better names) quick-paste and clipboard-paste. quick-paste (X11 stype: shift-insert, middle button) pastes the contents of the selection, regardless of the contents of the clipboard. Clipboard-paste (control-v, menuitem, toolbar, etc) paste the contents of the clipboard, regardless of the contents of the selection (recall that the clipboard does not change on selection).

And there was great peace and harmony among users of the clipboard (I hope) :-).

You're still with me? wow. 5 bonus points, and your further input on the subject deserves a moderation +1 informed :-)

I've been thinking and wondering about this for a long time -- where in the X code is the usual X selection and copying mechanism implemented? E.g. is it in Xlib, or even lower than that, or maybe somewhere else? How hard would it be for someone to modify that behavior X system-wide (I'm assuming it would be fairly easy to modify just KDE's behavior if one knows what one's doing...)?