[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-bugs-dist
Subject: [Bug 86362] New: Klipper emits warnings when clearing clipboard:
From: Esben Mose Hansen <esben () despammed ! com>
Date: 2004-07-31 23:24:31
Message-ID: 20040731232431.8744.qmail () ktown ! kde ! org
[Download RAW message or body]
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
http://bugs.kde.org/show_bug.cgi?id=86362
Summary: Klipper emits warnings when clearing clipboard: Cannot
set X11 selection owner
Product: klipper
Version: unspecified
Platform: Compiled Sources
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: general
AssignedTo: pfeiffer kde org
ReportedBy: esben despammed com
Version: (using KDE Devel)
Installed from: Compiled sources
OS: Linux
When building with enable-debug=full, Klipper emit these warnings (see \
subject) when clearing clipboard. Digging in, it turned out that Klipper \
was fighting itself during clipboard clearings, like this:
1) Klipper uses clip->clear() to clear the clipboard data
2) Consequently, Klipper receives a signal saying that the clipboard has \
changed. So Klipper updates the clipboard 3) clip->clear() fails with the \
above warning because the change in 2) is newer than the change in 1)
The error is of course in 2) happing. This should perhaps be prevented by \
this code in clipBoardSignalArrived():
// Don't react on Klipper's own actions. This signal comes either
// from this process when it sets the clipboard (in which case ignoring
// it is OK) or when another process sets the clipboard, in which
// case this process should have got already SelectionClear from that
// another process and therefore it shouldn't think it owns the \
clipboard. if( selectionMode ? clip->ownsClipboard() : \
clip->ownsSelection()) { return;
}
The trouble is that Klipper does not actually own the clipboard for the \
first signal. In setClipboard() this is solved by blocking signals from the \
clipboard. Doing this for clearing works, and is attached as the simplefix \
patch. However, there is a warning attached to the relevant line in \
setClipboard():
clip->blockSignals( true ); // ### this might break other kicker applets
So, I've made an alternate patch that fixes the above block in \
clipBoardSignalArrived() so that all signals during Klipper's \
clipboardmanipulations are ignored, and not just those that happen to \
happen while Klipper owns the clipboard. This is done by setting a boolean \
while Klipper is manipulating the clipboard.For this patch, I have removed \
the blockSignals() code from setClipboard() as well. The patch is attached \
as noblock.
Use/ignore :o)
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic