Version: (using KDE KDE 3.1.2) Installed from: RedHat RPMs Everytime I select a bunch of text in Lyx (Qt version), klipper starts using a lot of cpu and doesn't react for a long while. I think, lyx has a particular way to handle text displayed but I can't understand why klipper should use some much cpu time. I know it may be not a bug of klipper itself but anyway it's really annoying so it's worth to check this.
How much is 'a bunch of text'? Only few characters, or large amount of text? What is your Qt version?
the longer the amount of text selected, the longer it takes klipper to react. I tried to select 4 words. It took about three seconds to display the selection list and again maybe 10 seconds to remove it when I clicked somewhere else on the display. The text selected was displayed. If I remember well, it wasn't always the case for larger parts of text. I use qt3.1.2 I have just tried using lyx compiled with xforms and no such problem appears. Everything's fine in this case. Well, that could be a work-around but I prefer the qt interface anyway.
WORKSFORME, redhat 7.3/9, using kde-redhat.sf.net's rpms of: kde-3.1.3, qt-3.1.2, lyx-1.3.2. Selecting text in lyx is near-instantaneous, whether it be a single word, or paragraph. What version of redhat are you using?
I am using a RH7.3 initial installation on which I made some updates. Besides I am using lyx1.3.1 maybe that's the reason or it has been fixed in 3.1.3
I just saw another strange behaviour with lyx-qt. Klipper enters in a loop ()eats 100% CPU) when doing spellchecking (with ispell) in lyx.
I don't have the problem with selecting text (LyX-Qt 1.3.4, qt-3.3.1, kde-3.2.1), but sometimes I have the same problem as "gallir" (klipper eats 100% CPU when doing spellchecking with ispell in LyX).
Are you sure this isn't this a duplicate of bug #68477?
No, it isn't the same bug. As written above, this bug causes klipper to use 100% cpu so it doesn't freeze as in bug #68477. I haven't found any means to stop it (as a keyboard combination like the other bug) when it doesn't stop itself but to kill it.
*** This bug has been marked as a duplicate of 84595 ***