Bug 84595 - selection from lyx freezes klipper
Summary: selection from lyx freezes klipper
Status: RESOLVED FIXED
Alias: None
Product: klipper
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: Carsten Pfeiffer
URL:
Keywords:
: 61814 62082 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-07-06 20:56 UTC by Rutger ter Borg
Modified: 2004-11-12 15:09 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rutger ter Borg 2004-07-06 20:56:07 UTC
Version:            (using KDE KDE 3.2.2)
Installed from:    Gentoo Packages
Compiler:          gcc (GCC) 3.3.3 20040412  Gentoo Linux 3.3.3-r6, ssp-3.3.2-2, pie-8.7.6
OS:                Linux

A selection of text is made in LyX (from www.lyx.org) will always freeze klipper

Steps to reproduce: 

- open lyx
- select some text
- click on the klipper icon
- entire KDE (or only will freeze for a few seconds or longer

Expected behaviour:

- normal popup of klipper, no freeze
Comment 1 Rutger ter Borg 2004-07-06 20:57:49 UTC
some typos: 

A selection of text that is made in Lyx ...
- entire KDE (or only klipper) ...
Comment 2 Ingar Pareliussen 2004-09-02 11:01:07 UTC
I have some pieces of information I hope can help to locate the problem...

I have this problem with one of the two PC's I use. Both use SuSE 9.1. The only two differences I can think of is that the one with the bug uses usb-mouse and have a matrox G400 card. I do not know how this could cause these kind of problems, but I thought I should mention them. 

The problem also manfist itself if you try to change the virtual desktops when something is selected in lyx. This does, however, freeze even kicker. But the rest of the system are responsive... 

Another pice of information is that when I run lyx with -dbg 8, 
I get thousands of X requested selection, and then 
Lost selection. and then a bit later everything returns to normal.

I hope this help :)
Comment 3 Lubos Lunak 2004-11-10 18:26:33 UTC
CVS commit by lunakl: 

Protection against too many clipboard data changes. Lyx responds to clipboard data
requests with setting new clipboard data, so if Lyx takes over clipboard,
Klipper notices, requests this data, this triggers "new" clipboard contents
from Lyx, so Klipper notices again, requests this data, ... you get the idea.
Not that this doesn't really fix Lyx, almost no app is capable of retrieving clipboard
data from it, but the bug is in Lyx after all.
BUG: 84595


  M +24 -1     toplevel.cpp   1.158
  M +5 -1      toplevel.h   1.53


--- kdebase/klipper/toplevel.cpp  #1.157:1.158
@@ -61,9 +61,15 @@
 #define EMPTY (m_popup->count() - MENU_ITEMS)
 
+// Protection against too many clipboard data changes. Lyx responds to clipboard data
+// requests with setting new clipboard data, so if Lyx takes over clipboard,
+// Klipper notices, requests this data, this triggers "new" clipboard contents
+// from Lyx, so Klipper notices again, requests this data, ... you get the idea.
+const int MAX_CLIPBOARD_CHANGES = 10; // max changes per second
+
 extern bool qt_qclipboard_bailout_hack;
 
 // config == kapp->config for process, otherwise applet
 KlipperWidget::KlipperWidget( QWidget *parent, KConfig* config )
-    : QWidget( parent ), DCOPObject( "klipper" ), m_config( config )
+    : QWidget( parent ), DCOPObject( "klipper" ), mOverflowCounter( 0 ), m_config( config )
 {
     qt_qclipboard_bailout_hack = true;
@@ -73,4 +79,7 @@ KlipperWidget::KlipperWidget( QWidget *p
     m_selectedItem = -1;
 
+    connect( &mOverflowClearTimer, SIGNAL( timeout()), SLOT( slotClearOverflow()));
+    mOverflowClearTimer.start( 1000 );
+
     QSempty = i18n("<empty clipboard>");
 
@@ -637,4 +646,6 @@ void KlipperWidget::slotMoveSelectedToTo
 void KlipperWidget::newClipData()
 {
+    if( ++mOverflowCounter > MAX_CLIPBOARD_CHANGES )
+        return;
     bool selectionMode;
     QString clipContents = clipboardContents( &selectionMode );
@@ -645,4 +656,6 @@ void KlipperWidget::newClipData()
 void KlipperWidget::clipboardSignalArrived( bool selectionMode )
 {
+    if( ++mOverflowCounter > MAX_CLIPBOARD_CHANGES )
+        return;
     // Don't react on Klipper's own actions. This signal comes either
     // from this process when it sets the clipboard (in which case ignoring
@@ -753,4 +766,14 @@ void KlipperWidget::setClipboard( const 
 }
 
+void KlipperWidget::slotClearOverflow()
+{
+    if( mOverflowCounter > MAX_CLIPBOARD_CHANGES ) {
+        kdDebug() << "App owning the clipboard/selection is lame" << endl;
+        // update to the latest data - this unfortunately may trigger the problem again
+        newClipData();
+    }
+    mOverflowCounter = 0;
+}
+
 QStringList KlipperWidget::getClipboardHistoryMenu()
 {

--- kdebase/klipper/toplevel.h  #1.52:1.53
@@ -21,4 +21,5 @@
 #include <qpixmap.h>
 #include <dcopobject.h>
+#include <qtimer.h>
 
 class QClipboard;
@@ -110,4 +111,5 @@ private slots:
     void slotAboutToHideMenu();
 
+    void slotClearOverflow();
 
 private:
@@ -120,4 +122,5 @@ private:
     QString m_lastString;
     QString m_lastClipboard, m_lastSelection;
+    int mOverflowCounter;
     KPopupMenu *m_popup;
     KToggleAction *toggleURLGrabAction;
@@ -139,4 +142,5 @@ private:
     int URLGrabItem;
     KConfig* m_config;
+    QTimer mOverflowClearTimer;
     ClipboardPoll* poll;
     static KAboutData* about_data;


Comment 4 Lubos Lunak 2004-11-12 15:07:53 UTC
*** Bug 62082 has been marked as a duplicate of this bug. ***
Comment 5 Lubos Lunak 2004-11-12 15:09:29 UTC
*** Bug 61814 has been marked as a duplicate of this bug. ***