[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: QLineEdit
From:       Scott Wheeler <scott () slackorama ! net>
Date:       2002-02-20 18:43:06
[Download RAW message or body]

Ok, this *feels* right to me, because it explains a lot of things--including 
why I was having trouble finding the problem.  You kick butt!

I've currently having some problems building qt-copy.  I did a "cvs up" and 
it's not building properly now, so I'm checking out a clean copy.  It might 
take me an hour or so to get it back up and going, but I'll confirm this as 
soon as I can.

Also, I was wrong earlier.  This *should* fixes things in QComboBox too, I was 
using a Qt only app to test a QLineEdit and Konq to test QComboBox.  Even 
though I closed and restarted Konq, it was probably still launched with 
kdeinit and so didn't reload the Qt references.

-Scott

On Wednesday 20 February 2002 01:07 pm, Mickael Marchand wrote:
> hi,
>
> another update to our problem :)
> can you try a simple test ?
> use a non-patched QT (with deselect() uncommented)
> and try to turn off the 'synchronize' option in _klipper_ :) (yes that
> could be that one ;p)
> for me that works !
>
> my idea is that klipper watchs QT's clipboard, when it sees a new selection
> it calls a setText() method on QClipboard, _but_ this setText() method
> calls a setData() which emits a selectionChanged() or dataChanged()
> signals. This signal is certainly received by QLineEdit() which then
> deselect() what we just selected ! (read it twice to understand ;p)
>
> here is a sum up of the recursive calls :
>
> QlineEdit:
> selection updates QClipboard (i don't know really where but this looks
> logical)
>
> Klipper:
> newClipData (called every seconds to check the contents of QT's clipboard)
> -> setText() (called on QClipboard when its contents is updated, why is it
> here ? ?) -> other Klipper stuff
>
> QClipboard:
> setText()->setData() (defined in qapplication_x11.cpp) -> emit
> SelectionChanged / dataChanged()
>
> QLineEdit:
> receives the previous signal emitted by QClipboard, then deselects
>
> if Scott confirms, the next question will be how to fix it ?
> for me it's a klipper bug...
> but specialists of klipper may have a good explanation for all of that :)
>
> Cheers,
> Mik (tired of restarting KDE ;p)

[prev in list] [next in list] [prev in thread] [next in thread]