[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-20 22:00:16
[Download RAW message or body]

On Wed 20. February 2002 21:59, Scott Wheeler wrote:
>
> So, there are a few things here.  First I don't see why this is done by
> polling
>
> ===
> m_checkTimer = new QTimer(this, "timer");
> m_checkTimer->start(1000, FALSE);
> connect(m_checkTimer, SIGNAL(timeout()), this, SLOT(newClipData()));
> ===
>
> instead of
>
> ===
> connect(clip, SIGNAL(selectionChanged()), this, SLOT(newClipData()));
> ===
>
> 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.

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