------- 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)