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

List:       kde-core-devel
Subject:    Re: QLineEdit (and Klipper)
From:       Lubos Lunak <l.lunak () sh ! cvut ! cz>
Date:       2002-02-21 7:38:12
[Download RAW message or body]

On Wed 20. February 2002 23:13, Scott Wheeler wrote:
[snip]
> > > This produces what to a user (i.e. me) seems like strange behavior if
> > > they haven't seen the code.  If you select something for half of a
> > > second, it has a 50% chance of being in the clipboard.  It would be
> > > nice if one of the Klipper developers could comment on this.
> >
> >  I think selectionChanged() won't be emitted when the selection is owned
> > by a non-Qt application and it changes (i.e. if you select some text in
> > xterm and then another one, klipper wouldn't know about the second one
> > with selectionChanged() ). When this happens, other apps have no chance
> > to detect it, because nothing for them changes. The non-Qt application
> > still owns the selection, and only when it's asked for the selection
> > data, the non-Qt apps send something different than the last time. Qt
> > apps use a root property QT_SELECTION_SENTINEL for such notifying, so for
> > them it would work. Also, decreasing the timeout wouldn't be probably
> > that great idea, as it would generate more traffic.
>
> Ok, that's what I was missing.  That makes sense.  Then, I think it might
> be a good idea to have both connections.  This would make the responce nice
> and quick from Qt and KDE applications.  What do you (and others) think
> about that?

 Sounds like a good idea (who uses non-Qt apps anyway >;)  ).

 I haven't followed this thread before, so now I've read it. From the older 
posts:

On Wed 20. February 2002 03:05, Scott Wheeler wrote:
> Your question is good.  What should KDE do with the selection when
> something is selected in another app?  It seems that this is inconsistent
> between apps.
>
> For instance, if I select something in Konsole and then in KMail my
> selection is removed from the Konsole.  However, if I select something in
> Konq and then go to KMail, my selection in Konq stays.

 If you're talking about www pages here, then I think it's a KHTML bug that 
the selection stays even after something is selected in other app.

On Wed 20. February 2002 19:07, Mickael Marchand wrote:
> 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

 I think this last step is the problem. IMHO QLineEdit shouldn't deselect 
when the clipboard changes, only when selection does, because these two 
things are different, and selected text in QLineEdit shows selection 
contents, but not necessarily the clipboard contents. Making QLineEdit 
deselect only when the selection changes should fix the problem (and since in 
order to change the clipboard you have usually the change the selection 
first, it shouldn't break anything).

-- 
 Lubos Lunak
 llunak@suse.cz ; l.lunak@kde.org
 http://dforce.sh.cvut.cz/~seli
[prev in list] [next in list] [prev in thread] [next in thread]