[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]