84595 2004-07-06 20:56:06 +0000 selection from lyx freezes klipper 2004-11-12 15:09:29 +0000 1 1 10 Unmaintained klipper general unspecified Gentoo Packages Linux RESOLVED FIXED NOR normal --- 0 rutger pfeiffer gallir jerome l.lunak 0 oldest_to_newest 246318 0 rutger 2004-07-06 20:56:07 +0000 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 246319 1 rutger 2004-07-06 20:57:49 +0000 some typos: A selection of text that is made in Lyx ... - entire KDE (or only klipper) ... 265137 2 ingar.pareliussen 2004-09-02 11:01:07 +0000 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 :) 284626 3 l.lunak 2004-11-10 18:26:33 +0000 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; 285204 4 l.lunak 2004-11-12 15:07:53 +0000 *** Bug 62082 has been marked as a duplicate of this bug. *** 285207 5 l.lunak 2004-11-12 15:09:29 +0000 *** Bug 61814 has been marked as a duplicate of this bug. ***