Help needed - klipper bug or X bug or krita bug

[Lubos Lunak]

On Monday 06 February 2006 23:34, Boudewijn Rempt wrote:
> On Monday 06 February 2006 23:43, David Mulcahy wrote:
> > Hello All
> >
> > I am Trying to find a bug that first appeared in gimp (see this
> > for more http://bugzilla.gnome.org/show_bug.cgi?id=327910)  Now
> > this seems to be a bug in klipper or X.  The following is output
> > from krita 1.5 beta1 when cutting a very large selection from a
> > jpeg.  Everything seems to grind to a halt for a while.  Do the
> > following errors look normal for krita or does this seem to
> > indicate a bug in klipper or X.  I only get these only when
> > klipper is running.  If i close klipper the errors do not appear
> > and everything seems to run a bit faster.
> >
> > Thanks in advance for any help you can shed on this
>
> Hm... This sounds exactly like what Lubos was talking about on his blog
> (http://www.kdedevelopers.org/blog/280). I'll cc him: maybe he can tell me
> what I'm doing wrong.
>
> The relevant errors are:
>
> X Error: BadWindow (invalid Window parameter) 3
>   Major opcode:  18
>   Minor opcode:  0
>   Resource id:  0x1800014
...
> X Error: BadWindow (invalid Window parameter) 3
>   Major opcode:  18
>   Minor opcode:  0
>   Resource id:  0x1800014
> QClipboard: timed out while sending data
> X Error: BadWindow (invalid Window parameter) 3
>   Major opcode:  2
>   Minor opcode:  0
>   Resource id:  0x1800014
> QClipboard: timed out while sending data

 These are just BadWindow X errors, they don't necessarily mean real errors. 
There's actually no real problem, is there? 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.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/