KDE 2.2.2 Released

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 available
here.
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 is
scheduled
in about 3 months. Happy Thanksgiving!

Dot Categories: 

Comments

by Janne (not verified)

Off to download (that is, if Debian-packages are ready)!

by ac (not verified)

not yet..

by ealm (not verified)

It is in sid!!!

by Janne (not verified)

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 ;)

Thank you for an excellent desktop! Looking forward to KDE 3.0!

by lanbo (not verified)

I cannot believe it's so easy for RedHat! Finally!
Thanks Kde developers.
I really hope it'll be faster... :-)

by emuman (not verified)

Yes, no problem this time for Redhats.
KDE 2.2.1 was cool, KDE 2.2.2 is faster, has less bugs, simple great!
What comes with 3.0? Orgasm while using it?

by Joe Reale (not verified)

I downloaded all the RPMs, burnt a CD and installed all the packages in less than 30 minutes !

My RedHat 7.2 / KDE is now flying !

Many thanks.

Joe

by Rick Loga (not verified)

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.

by Asif Ali Rizwaan (not verified)

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.

Hope this helps. Rpmfind.net is a nice place for rpm users. :)

by Iuri Fiedoruk (not verified)

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.

I don't know if those redhat 7.2 rpms on the kde.org ftp are the same, if not here goes the url:
ftp://ftp.opennms.org/people/ben/redhat-7.2/RPMS/

by Oliver (not verified)

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?!

by shivers (not verified)

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].

Slashdot story here: http://slashdot.org/article.pl?sid=01/11/22/141233&mode=thread

Bero's link to prelink here: ftp://people.redhat.com/jakub/prelink/

by David Faure (not verified)

Doesn't objprelink make all webpages with javascript crash konqueror ?

AFAIK it does - both SuSE and Mandrake tried to make packages with objprelink, and in both cases khtml was crashing when dlopening kjs.

Is this about another kind of objprelink ?

by Iuri Fiedoruk (not verified)

Well, I tested and javascript isn't crashing konq here.
Maybe it's a version of objprelink that dosen't have this bug anymore.

by Joe (not verified)

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.

by David Faure (not verified)

But javascript support in 2.x was quite incomplete, so websites could easily crash konqueror.

Javascript in KDE 3.0-CVS is activated by default, and is much much better.
It will make you come back to Konqueror, I can assure you.

David, currently ironing out the last KJS bugs, and closing tons of bug reports...

by Joe (not verified)

Well, that's just great! And thank you for a kind and friendly answer as usual, Mr. Faure.

by cbcbcb (not verified)

Have they fixed the bugs in kwin which cause to to variously freeze up and/or crash? I reported this for 2.2.0 and it was still broken in 2.2.1.

I'm using packages from Debian unstable.

(To reproduce, hammer all the mouse buttons and keep pressing Ctrl-Tab until it stops working. To recover, right click on the title bar of a window)

by Andreas Pietzowski (not verified)

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

by Anno v. Heimburg (not verified)

(To reproduce, hammer all the mouse buttons and keep pressing Ctrl-Tab until it stops working. To recover, right click on the title bar of a window)

As a warkaround: Don't do the above. Use a punshing ball for your aggressions instead ;-)

Greets,

Anno.

by MwtrV (not verified)

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.

by Loranga (not verified)

From the announcement:

Library Requirements. KDE 2.2.2 requires the following libraries:

Qt-2.2.4, which is available in source code from Trolltech as qt-x11-2.2.4.tar.gz, though qt-x11-2.3.1.tar.gz (rather than Qt-2.3.2) is recommended;

by Sashmit Bhaduri (not verified)

2.3.2 was deemed to be buggy

by Christian (not verified)

I do confirm.
Moreover, some KDE packages miscompile with it
(easy to fix, but 2.3.2 is not advisable).

by cyanide (not verified)

As usual, Mdk seem to use it anyway...

by shivers (not verified)

As do RedHat...

I've only been using it this afternoon, but no problems so far...

Downgrading to 2.3.1 is recommend, because 2.3.2 + klipper => slow kfm.

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.

Dont beat me, please

where can I get qt 2.3.1 rpms for my SuSE 7.3 box?

And why not qt3???

Available at trolltech ftp: qt-x11-free-3.0.0.tar.gz

Using it with rh7.2. Run fine but takes a _LOT_ of time to compile even on my smp box.

by Bryan Feeney (not verified)

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 ;-)

by bruno m. (not verified)

I have to ask, since I'm considering setting up a FreeBSD box after leaving it a few years ago: will '2.2.2 packages be made for it (i.e. for V4.4)?

Actually, will the KDE project endeavour to make 'BSD packages for KDE 3.x, or is it the responsability of the various 'BSD projects?

Thanks.

by Rinse (not verified)

KDE only supplies sources, the Unix-Linux teams are responsible for the corresponding binairies etc...

by Ilya Martynov (not verified)

KDE have been supported in FreeBSD port collection for long time. 2.2.2 is not yet where but I suppose ports will be updated soon.

by David Johnson (not verified)

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.

by new suse user (not verified)

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?

by new suse user (not verified)

never mind, I got it. (its YaST not YaST2!)

by gunnar (not verified)

thanx for the work. its very nice and i love it.

-gunnar (a very happy kde user)

by 1st Time Write (not verified)

Perfect... but:
what about diffs?

by Hywel Mallett (not verified)

http://www.hmallett.co.uk/diffs/ may be just what you need...

by 1st Time Write (not verified)

Perfection again(for a slow connection like mine) :)-><
!!!!Thank you!!!!

by Sam Halliday (not verified)

YOURE KIDDING!!!!!

i am honestly on the last 5 minutes of downloading the sources on my 56K connection at home, i searched and i searched, but i did not find!!

ill know for again,

Sam, Ireland

by Hywel Mallett (not verified)

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.

Hywel Mallett

by Sam Halliday (not verified)

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.

Sam, Ireland

by new suse user (not verified)

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").

Thank you.

by Kevin Puetz (not verified)

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.

by Kevin Puetz (not verified)

crap, how in the world did this doublepost. grr... read the one below, this one I thought I had only previewed, then fixed a few typos.

by Kevin Puetz (not verified)

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 :-)

by Rakko (not verified)

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...)?