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 Kevin Puetz (not verified)

nowhere (or everywhere, whichever view you like). X provides ways to read and set various tokens called atoms. At the protocol level, that's about all it does (that I know of) to support things like clipboards. As far as the Xserver is concerned, they don't really exist, it's just shuffling data around on behalf of it's clients.

At a slightly higher level, some atoms (like the ones used to implement the clipboard) have existed for so long that they might as well be part of the protocol; they are simply presumed to exist and to be used for certain purposes. Apps, however, are still free to set/read them as they wish (following their intended purpose). Things like middle-click pastes PRIMARY, selection sets PRIMARY, etc are nothing but convention, though they been followed by apps since... well, a long time anyway. But the Xserver couldn't care less. An app could set the clipboard to a random string whenever a key is pressed, if it wanted to.

The codification of the programming conventions for using these 'standard' atoms is the ICCCM (inter-client communication conventions manual). Google should turn up a copy easily enough, if you actually want to read it. Most windowmanagers and apps try hard to conform to this. Failure here means your app is not a good citizen :-). At the least, it probably won't be able to share it's clipboard contents with other apps, and it probably won't work correctly on many other things the ICCCM covers either.

Thankfully, apps don't have much to get right here though, so most do just fine... it's windowmanagers that have to be careful, as they facilitate a great deal of the interaction. Windowmanager compatibility bugs are certainly seen sometimes :-)

Actual userinterface conventions are (technically) left to the apps... they can change these core atoms at any time, for any reason. However, precedent is very strong, and not to be lightly ignored; toolkits also often enforce policy on a lot of these issues (and how many apps are really written straight to Xlib anymore).

KDE (or rather, QT) could easily manage the selection differently from accepted behavior if it desired to. Qt2 does, though for what reason I don't know - it's certainly not popular that it treats CLIPBOARD and PRIMARY as equivalent (hence posts like the parent). From a user-confusion point of view you'd want to be really sure it was worth it if you were going to deviate; I think qt2/kde2's behaviors probably stem from QClipboard seemingly having grown up on win32; I claim no proof of this other, it just seems somewhat likely since it doesn't handle X11 clipboards quite right. No flames please :-)

So... changing the clipboard convention basically involves (at a basic level) changing all the apps. If you really wanted to do this, it's probably a lot easier than it used to be, because so much of what X considers 'app' is really 'toolkit' nowadays. Toolkits centralize a lot of the policy code that X intentionally refused to define, and relate to the app at a much higher level; that's a big part of what they offer the application developer.

Qt and GTK both provide clipboard services to their apps, so just changing the toolkit can change the behavior of a lot of apps (for instance, qt3 got fixed, so all kde3 apps are now fixed). I don't know if motif did - I suspect it did. So, changing those 3 would probly hit 95% of the apps the typical linux user runs nowadays. Might be possible... but far from trivial :-).

hmm... I must be bored, this post too grew to immense length :-)

by Rakko (not verified)

Well, thanks for the lesson :) I remember asking the same question once on IRC, and someone told me it wasn't handled in the toolkit, but rather in Xlib. I've been meaning for about five years now to read the book I got on Xlib programming, but I only finished a few chapters and don't really retain any of it now. As for throwing off standards, I am well aware of how that can be a Bad Thing, but I only want to change selection behavior on my own computer, which pretty much only I use.

by Rakko (not verified)

Well, thanks for the lesson :) I remember asking the same question once on IRC, and someone told me it wasn't handled in the toolkit, but rather in Xlib. I've been meaning for about five years now to read the book I got on Xlib programming, but I only finished a few chapters and don't really retain any of it now. As for throwing off standards, I am well aware of how that can be a Bad Thing, but I only want to change selection behavior on my own computer, which pretty much only I use.

by Kevin Puetz (not verified)

yeah. Well, as far as UI behaviors go, you can freely change that and still be interoperable. If you got Qt and GTK, you'd be well along in getting most of the apps you use to change, I suspect. Good luck :-)

by geekster (not verified)

I like new suse user's idea better. It's easier. You can select and copy using only the mouse. Plus you can select and ctrl+c as in windows. And if you want to do it the unix way you could just switch the roles of the left and middle buttons so the middle would be select and the left would be copy (possible some option Control Center).

by Kevin Puetz (not verified)

With the new scheme, you can treat it exactly like windows.
If you don't paste with the middle-mouse, the selection is irrelevant.
Or use the mouse only (in which case the clipboard is irrelevant). Whichever you prefer :-) You can even use both, making quick pastes from the selection with middle-mouse without disturbing your clipboard contents.

The middle mouse button pastes whatever is selected (no need to hit copy).
Control-V (or menus, etc) pastes whatever was last copied, even if the selection has changed since then. Both systems work as expected, with no need for options. That's a Good Thing (tm). At least, I think so. But my opinion means no more than yours anyway :-) I should clarify that, lest someone get the idea from all my postings here that I actually maintain the code in question (not so).

kde2's behavior really bugged me, kde3's (which is the same as most other X11 apps) seems quite sane. At least give it a chance :-)

by new suse user (not verified)

First of all thank you for enlightening me. I am not an advanced programmer (only a student) so many things were quite new to me.

Secondly, I welcome all the improvements in KDE 3 clipboard handling. The inability to paste over in KDE 2.x irritated me for some time now. However, while, windows-like (I come from windows) ?ctrl+c/ctrl+v? cut & paste mechanism has its certain advantages, I cannot say that I like it, or that it is done the best possible way; and even though, KDE 3 provides both ?ctrl+c/ctrl+v? and ?copy on select/middle mouse button paste? mechanisms, I think that it only creates a choice (which is good) between two fairly wide spread, but not necessarily the best schemes possible (I doubt that many people will be using both at the same time). I kind of like the idea that one does not need a keyboard to copy and paste, and I was very exited that all copying and pasting in Linux bypasses it (that is until I realized that there is no ?past over?). So the idea that I can copy, paste or paste over by using just a mouse seems intriguing to me.

Thirdly, I understand that implementation might be quite difficult (which I think it should not be, of course I may be wrong), or that it might conflict with some standards (which I think it does not have to). As I understood from the posts above (boy, that was some reading), the selection and cut & paste mechanisms are not imposed by X windows system, but are rather handled by the applications (or in most cases by the toolkits upon which the applications are built), so it may not be a KDE issue by a qt one. However, I don?t think it should be too difficult to allow a selection by using a middle mouse button (just a duplication of what is implemented for the left mouse button). So that it would be possible to select (just select) by holding down the middle mouse button. After that is done, there needs to be an option somewhere in qt or KDE (it might be even a compile time option) such as:

1. Copy to the clipboard on left mouse button selection
or
2. Copy to the clipboard on the middle mouse button selection

This way a user can decide which way he/she wants to go and if he/she wants to have a consistent clipboard between apps or if he/she can sacrifice some consistency for the ease of use. This should not be too hard to implement either (or am I dead wrong on that one?).

And if all major toolkits will implement it then there will be no need to sacrifices anything. (am I being to naive?)

by Ryan (not verified)

One question. So if middle mouse button pastes the selection and Ctrl-V pastes the clipboard. How can i paste into Konsole? It took me awhile to figure out the only way was with the middle mouse button. So does this mean no clipbord into konsole?

by Anonymous (not verified)

Edit/Paste? Right mouse button menu/Paste? Shift-Insert?

by Anitha Srinivasan (not verified)

Hi.. i have a problem with copy-paste in KDE- FreeBSD box.
When i select some text on any application, and whn i try to paste to another or same application by using middle-mouse click, it gets pasted perfectly. But whn i try to do shift+insert, its not getting pasted.

Pls tell me wht to configure as wht to enable shift+insert wrk to paste the selected text.
TIA

Rgeds,
Anitha

by hackorama (not verified)

Does anybody had any luck with Codeweavers Crossover plugins on Konqueror with KDe 2.2.2 ?

by Timothy R. Butler (not verified)

I had moderate success with it in KDE 2.2.1, so I am assuming it will work in 2.2.2 too. The only strange thing was that rather than embedding the plugin, a little seperate window opened that contained the plugin.

-Tim

I think I will love this plugin but how can I install and test it ?
I've never seen it in action. Do I need extra packages, is it in the konqueror-package?
I'm running debian unstable.

thanks

have fun
HAL

by Rajeev (not verified)

In my opnion KDE team should focus on speed ,usablity and memory footprint instead of adding new features.I think the features in Win95/98 are sufficient for average users,I hope that KDE will come to that level soon.
For third world countries in Africa,Asia ,the idea of free software makes lot of sense ,because it takes lot of financial burden from the government.But higher hardware requirements poses serious obstacle to main stream adoption.Presently KDE is so slugglish in my Pentium II/128mb Ram ,I prefer to use console.
I guess KDE team would recognize this fact
Good Luck
Rajeev

by Sam Halliday (not verified)

kde used to be very sluggish on my mandrake 8.1 machine, taking about 30 seconds to start up.. but i got so annoyed at their broken devfs, development c compiler and massive dependencies that i never understood how in earth they needed it all, that i got myself the Linux From Scratch ps document, and recompield it all.... now kde 2.2 starts in 10 seconds on a first boot, and applications taek no longer than a second. i used to blame kde for this slow behaviour, but i realised its the distro's fault.

Sam, Ireland

by Will (not verified)

I own a PII w/ 128MB RAM and occasionaly a few things are slow, but I've seen very good speed (since 2.2.0). Maybe there is a bottle neck somewhere else?

Will

by Asif Ali Rizwaan (not verified)

On RH 7.1, KDE 2.2.2 is twice faster than KDE 2.2.0 (atleast for me). KDE knows that the next priority is Speed along with Stability and Security. I am sure that KDE 3.x will be as faster as KDE 1.1.2 used to be.

by RedHat 7.2 User (not verified)

I have libxslt-1.0.1-3 installed but kdelibs also want to have libxsltbreakpoint.so.1

Any hints ?

by RedHat 7.2 User (not verified)

Ahh... I had to upgrade libxslt and libxml2 to the one in Rawhide

by Anonymous Crybaby (not verified)

I just installed the RPMS for RedHat 7.2, and it installed like a charm... the entire KDE overall seems much faster than the default KDE2.2.1 that came with RH7.2. Thank you Bero, and KDE Devs!

Has anyone gotten antialiased fonts to work with the RedHat RPMs? I had it working for the default install, but even after I click "antialias fonts," it still shows non-AA fonts.

Thanks in advance

by Matt Phillips (not verified)

Same thing happened to me with the Mandrake 8.1 packages. I had beautiful AA fonts until I upgraded to KDE 2.2.2. I checked, and the option is still ticked for AA fonts... Any ideas why they stopped working?

Change the /usr/bin/startkde file to include the following line somewhere in the beginning:
export QT_XFT=1

That would do the trick.
BTW, thislittle annoyance that has existed since the AA fonts in KDE were introduced. And nobody cares to repair that - neither the KDE team, nor the distro team. That's a very serious problem of either proprietary or OSS projects - they forget to repair those "little" buggies, while running for more and more new features. Just my opinion, though.

by Matt Phillips (not verified)

Strange... A reboot fixed it for me. I figured just restarting KDE would be enough to pick up any changes from the upgrade. Oh well. Works great now.

by sam mulvey (not verified)

Please tell me that there's a patch between KDE 2.2.1 and KDE 2.2.2. It seems for minor bugfix release, having to go and download the entire source all over again is a little wasteful.

Not everyone has extremely fast broadband connections.

by someone (not verified)

Reading other comments is not one of your strengths, eh?

by sam mulvey (not verified)

I looked. Apparently reading other comments isn't a stregnth. But I'm not apologising.

I found the patches from someone else later on, which saved the day, but it does bring up an important point. I know I've seen this request before, but since I haven't seen a solution. Why aren't patches officially released with the source? Why do I have to check IRC or the dot to find out where they are? If there's a good reason, I'll sit and deal with it, but I am curious.

by AC (not verified)

using the cvs to download works good with modem's too.
i think thats the reason why they don't supply patches.

by Tobias (not verified)

Hi!
It is wondeful to hear that so many other users did a successful update. Unfortunatly my system is partly broken now. Here is what I did and what is broken:

My system is a SuSE 7.1 install. Someday I updated KDE to V2.1.2 which worked fine.

Now I downloaded the update for KDE 2.2.2 for SuSE 7.1 from a mirror. I had to pull a new libxml2 and libxslt lib from the rawhide distro also. The only dependency I allowed RPM to ignore was cups (I have lprold installed).

If I startup my system now kdm shows up (the fonts have big pixels, but I don't really care) and I can log in. KDE itself starts up. I get a error message:

"Protokoll wird nicht unterstützt: file"
my translation: "Protocol not supported/bound: file"

All my icons from the desktop are gone. My "K" Menu is nearly empty, only the very basic stuff in it (If I start the menueditor I still can SEE all the menu entries in the editor!!!). If I start Konqueror it tells me
"Protocol not supported/bound: http".

Hmmm, something definitly broke.

Any suggestions where to start to look/what to do ?

TIA,
Tobias

by roger (not verified)

You probably should download all files from one location: eg the SuSE LinuKS website (SuSE's KDE sevice on their website: support/download-section). There are libxml2 and several other files that you might need or want as well.

by Sebastian Eichner (not verified)

Hi,

You probably did not run SuSEconfig after installing the RPMs.
I had these problems a few KDE-versions ago.

Try the following:

1. Run SuSEconfig. If it works now, fine. Stop here.
2. In a shell, run "kbuildsycoca" as normal user, and maybe as root too.
3. Start up kde, is it working now?
4. If not, try to move away your ~/.kde2 directory (rename it) and start kde again. KDE will build a new ~/.kde2 dir, but your settings for backgraounds, fonts, programs etc. will be lost. After that, you can try to copy certain files from the old .kde2-dir to the new one. Did this thelp you?

5. If not: Hmm, dunno....

Good luck,
Sebastian

by Tobias (not verified)

> 1. Run SuSEconfig. If it works now, fine. Stop here.

It "fixed" the kdm appearance to look ok again. No effect on the desktop.

> 2. In a shell, run "kbuildsycoca" as normal user, and maybe as root too.

User: Didn't work before step 4, complained with soemthing like "unable to open database".
root: "Warning: kbuildsycoca is unable to register with DCOP."

> 3. Start up kde, is it working now?

nope.

> 4. If not, try to move away your ~/.kde2 directory (rename it) and start kde again. KDE will build a new ~/.kde2 dir, but your
> settings for backgraounds, fonts, programs etc. will be lost. After that, you can try to copy certain files from the old .kde2-dir to
> the new one. Did this thelp you?

This one is funny. I moved it away. The desktop was rebuild. But all my icons are THERE again and the K menu is full again. Two drawbacks: all "umlauts" are broken in the menus and my Netscape 4.7x has all menus written in CHINESE (no kidding) signs now ?!
Only Konqueror lost his config and doesn't know how to display umlauts.

> 5. If not: Hmm, dunno....

I just finished downloading all the RPMs directly from SuSE again. Will try to install these. If I don't come back here it DID NOT work.

PS: Lots of new snow here in Germany today ;-)

by Tobias (not verified)

I can't you tell why, but copying back the backup of my .kde2 dir that I made right after the update fixed a lot of problems.
Additionally I installed the packages I got from SuSE directly. That fixes some more things.

At the moment the only problem left seems to be the fonts:
Only Arial is available everywhere. I will look into that later. Thanks for all the help so far guys !

by Kevin Puetz (not verified)

ahh... I bet you turned on antialiased fonts, and don't have any truetype ones except arial. When antialiasing is on, only truetype/type1 fonts are available in KDE.

Either turn it back off (kcontrol:look&feel:fonts) or find one of the font-antialiasing howtos to setup your system for it.

by DiCkE (not verified)

As root do: fetchmsttfonts.

by RedHat 7.2 User (not verified)

RH7.2 with 2.2.2.

When I do a web download, or web upload or just starts kate with a previously saved file it can take 2 or 3 minutes before I see the actual file loaded...

Any clues ?

by Rajan Rishyakaran (not verified)

For the first time ever, no RPM problems! Kudos to all RPM makers :-)

by Jim C (not verified)

Usually Caldera is one of the first to release rpm packages for KDE releases. Unfortunately, they aren't there yet. I hope Caldera is planning on making packages. If so, does anyone know when they will be available or what the delay is?

by sniggly (not verified)

Is the kio_sftp module a part of this release? I am SO looking forward to that - almost as much as to having return to castle wolfenstein....

by Carbon (not verified)

Well, if you're using Debian Woody or Sid, you can install the FISH KIO module from online using apt-get, though the package name esacapes me at the moment. Dselect time!

by poppafuze (not verified)

apt-get install kio-fish

by Sam Halliday (not verified)

well done to the team, altough i was a bit piss*d off when i compiled the whole thing to realise that i needed xml-2.4.8 AND libsxlt to get some vital components to compile (kdb2html being a prime candidate)... i didnt read this on the announcement page! but not to worry, i am finishing the download of sxlt now and ill run that compile-all script again.

BE WARNED ANYBODY WHO DOESNT KNOW ABOUT THIS REQUIREMENT!!!

Sam, Ireland

by Marko Rosic (not verified)

Nothing much to say... here's a part of log after runing make -f Makefile.cvs

*** Creating Makefile templates
kdoctools/libxslt/Makefile.am:42: variable `M_LIBS' not defined
make[1]: *** [cvs] Error 1
make: *** [all] Error 2

Please help

by jamal (not verified)

didn't read compilation faq yet , eh ? :)
read it.. on number 1

by Marko Rosic (not verified)

Yup... that did it :)
I've used the ones from cvs though.

by Paul Mitcheson (not verified)

First of all let me say the following before you start flaming me...

I use KDE on my desktop at home and at work, and it's great. I really appreciate all the effort people are putting in. I will also say, before somone suggests, that I don't have time to do any coding on the project.

However... although KDE is improving from release to release, I still do not feel that the 2.x branch (even with 2.2.2) has reached the quality needed for KDE to be accepted by normal business users. There are too many little things that are not right.

For instance, when I apply a new widget style, it doesn't apply properly until I log out and in again, and it screws up the colour scheme.

Konqueror still does not draw many pages properly. Or perhaps it does not draw (and run Java Script) in a way compatible with IE, for which the pages are written. Either way, I can't view all web content with it.

There are a few other small things which I can't remember off hand...

Anyway, this brings me to the point that I think someone should continue to develop 2.x code until it is 100% right. It should not be dropped while everyone works on KDE 3.

I remember a discussion a while ago about treating KDE development like the linux kernel development, but for some reason which I can't remember, the idea was shot down.

What does everyone else think?

Paul

by Eron Lloyd (not verified)

Hello, Paul

I think I speak for everyone by saying that although I agree that KDE 2.x *may* not be 100%, there is no good reason NOT to keep moving forward, which right now requires us to shift up to QT 3. There are enourmous benefits from doing this, from performance gains to cleaner internal APIs, etc. The shift from 2.x to 3.x will be far less dramatic than the 1.x to 2.x process. Humbly, I am confident in saying that no code is ever quite 100%, yet as of now I think KDE is probably at 89.9%, compared to alternatives :-). Also, from the problems you are experiencing, it sound more like the distro's packaging or a configuration problem. I've not had a serious issue at all for some time on my SuSE setup. Maybe you should try the mailing list.

Regards,

Eron

by Paul Mitcheson (not verified)

Hi Eron,

I'm affraid I am using SuSE 7.3 at work, with their official packages. My flat mate uses it at home, and he too suffers the same problem with widget styles.

I also suffer the same probs at home on Solaris.

> There is no good reason NOT to keep moving forward

Sure, so the KDE community should continue work on 2.x at the same time as 3.x

Paul

by Eron Lloyd (not verified)

Hello, Paul

I think I speak for everyone by saying that although I agree that KDE 2.x *may* not be 100%, there is no good reason NOT to keep moving forward, which right now requires us to shift up to QT 3. There are enourmous benefits from doing this, from performance gains to cleaner internal APIs, etc. The shift from 2.x to 3.x will be far less dramatic than the 1.x to 2.x process. Humbly, I am confident in saying that no code is ever quite 100%, yet as of now I think KDE is probably at 89.9%, compared to alternatives :-). Also, from the problems you are experiencing, it sound more like the distro's packaging or a configuration problem. I've not had a serious issue at all for some time on my SuSE setup. Maybe you should try the mailing list.

Regards,

Eron

by Aaron J. Seigo (not verified)

> What does everyone else think?

that the work being done to bring KDE2 closer to 100% is called KDE3.

by Paul Mitcheson (not verified)

Aaron,

I appreciate that QT3 has more features and better designed interfaces, but there are differences with QT2. Won't there therefore be more problems with KDE3 because of this move - ie I don't believe kde3.0 will be as bug free as 2.2.2 Perhaps I'm wrong on this issue, I hope so.

Regards,

Paul