Here’s a demonstration of how KDE4-s clipboard misbehaves, (the stands for sucks).
It’s been tested with
Mepis 8.48 kde4 desktop and FLWM
Mepis 8.5 kde4 desktop and FLWM
Open Suse 11.2 Gnome and icebox
Each of the above was demonstrated on an AMD and Intel platform.
I suspect that anywhere there’s a KDE4 app there’s this simple bug - at least.
open ANY kde4 application that has text input (even konqueror, konsol, kalarm, kjots etc ) - but lets use kwrite. This will be the text source for the clipboard.
open ANY other application (KDE or anything - even gterminal) - well use gedit. This will receive snippets of text from the kde source app.
3)In kwrite, enter these lines of text
a) kwrite ctrl+c
b) kwrite ctrl+x
c) kwrite shift+delete
d) kwrite just highlight me (middle click in other app)
Highlight a line and use the appropriate copy technique or cut as suggested. It doesn’t seem to matter if you highlight with the keyboard or the mouse.
Switch focus to the receiving app (alt+tab etc)
and paste using Ctrl+V or shift+insert (but use middle click for D)
Not that the new text is now entered into the receiving application (gedit).
switch back to the sending app (kwrite)
Note that the source text is gone. (this is OK for B and C but A and D are NOT CUT Commands but COPY )
Repeat steps 5 and 6 until all clipboard cut, copy and paste techniques have been tried.
reverse the operation by switching source and destination apps.
ie type this into gedit:
a) gedit ctrl+c
b) gedit ctrl+x
c) gedit shift+delete
d) gedit just highlight me (middle click in other app)
And you will notice that the behavior of lines A and D is correct = gedit and non kde apps ONLY SURRENDER CUT DATA.
Copied data remains in place.
data is lost from the kde4 source when the app recieves focus.
ctrl+z restores the data (A pain but it restores it without stealing t back from the other app).
you can paste the data back -without stealing t back from the other app!
(3-b really) subsequent pastes do not affect the previously selected source text.
you can copy and paste within the same app (not sure about different tabs) indefinitely and the source text remains in place
Since KDE4 apps (every one of those bastards) misbehave while non KDE apps function as expected (net beans, eclipse,opera,firefox, gedit, open office etc.)
A KDE shared library is the culprit [since only kde misfunctions]
Seems to be specifically a lostOwnership() type problem (or whatever signal handler is used) to notify the transfer [observation 3 and 4]
KDE 3.5 was perfect.
KDE 4 has so many other problems one can’t help but wonder if some parts of the linux community
A) has gone insane trying to outwow microsoft and apple desktops and are skimping basic functionality code
B) has been infiltrated by corporate spies from M$ and @pp]e to foul base code. Imagine that-getting paid to write bad code for free.
C) Too many out of work MS pros are boosting their resume with open source coding - thus influencing the overall library and effect.
Reduce expectations and develop patience and tolerance.
Don’t use KDE4 apps.
Back to 3.5 - oh, the pain
Wait for kde5 (or 6) - by then I’ll have to upgrade anyway
Write my own apps (not the best idea either).
I tried it with KDE 4.3.5 and gedit and it all worked as expected.
Have you tried to make a test user and see if that user has the same problem?
If he doesn’t have the problem it’s most likely that it’s a wrong setting in your user.
Thank you all-
This is the second time that SCIM scummed me.
I thought I had it disabled - there was no evidence that it was running.
I disabled it and KDE apps are working properly now.
That’s one bugaboo out of the way.
KJots is crucial to my deprecated method of coding and keeping info.