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