Help needed - klipper bug or X bug or krita bug

[David Mulcahy]

>
>  These are just BadWindow X errors, they don't necessarily
> mean real errors. There's actually no real problem, is there?

No real problem - only a simple (large) cut takes 1min 15 secs 
without klipper and 2mins 30 secs (for windows to resume 
responding) with klipper running.  

Thanks for taking the time and putting me straight on the 
problem.  I am a kde user exclusively and I just thought it was 
worth checking while krita is in beta mode.  

Thanks again  Dave

> The problem here is caused by the fact that Krita (and Gimp
> presumably as well) need some time to prepare large images for
> clipboard transfer. QClipboard on the other hand has a
> protection timeout that prevents applications from locking up
> if the other application doesn't respond, and it's currently 5
> seconds. So Klipper asks for clipboard contents, Krita takes
> more than 5 seconds to respond, and Klipper bails out. Those X
> errors just come from Krita trying to send the data when
> Klipper is not longer listening, it's harmless.
>
>  One thing that I've noticed that makes this worse, and
> probably also causes the Gimp crash, is that QClipboard when
> it fails to receive the data in one format then it tries to
> receive it using another one. Which in turn can result in
> Krita/Gimp attempting to send the image in several formats at
> once, and I guess Gimp can't handle that. I guess this could
> possibly be changed in QClipboard.
>
>  However, for KDE3.5.2 Klipper will default to ignoring images
> in clipboard, so there this problem shouldn't exist unless the
> user explicitly turns it on. This problem should be eventually
> solved by using reasonable limits with TARGET_SIZES during
> clipboard transfers.