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

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

Ok, turning off the option does fix things.  That explains a few things:

*) the delay between selection and deselection -- because it's called by a 
"polling" event rather than a signal/slot connection

*) why some people are having this problem and others aren't

*) why it seems like this hasn't always happened -- I'm guessing we all 
thought it started when we turned that option on, but didn't notice the 
connection.


On Wednesday 20 February 2002 01:07 pm, Mickael Marchand wrote:
> QlineEdit:
> selection updates QClipboard (i don't know really where but this looks
> logical)

Well, it updates the "selection" in QClipboard.  Everything else seems right.

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.

Second, it seems that that there needs to be a way to disconnect dataChanged() 
and selectionChanged() for the call to "clip->setText( clipContents );"

There are only a few ways I can think of doing this (though there may be 
more).  

The first would be to try to determine, in K/QLineEdit if the selection came 
from the current application and if so to not disconnect dataChanged() and 
selectionChanged(), but I don't know how that would work.

The second would be to petition TrollTech to add a method (or an additional 
parameter to QClipboard::setText) to QClipboard that would set the text 
without emitting the signals.  This would still have the problem that things 
wouldn't be deselected if a "first" application if something was selected in 
the "second", but that seems to be how things work now for most widgets.  

Third, there could be a KClipboard that reimplemented setText(), but it's not 
virtual (so there would have to be a change from TrollTech anyway) and this 
would cause Qt and KDE applications to behave differently.  This would be a 
lot of work (probably).

Also, this seems to work OK in other widgets, so I'll look into what they're 
doing differently.  It may be that I'm missing something that would make this 
much easier.

Cheers!

-Scott
[prev in list] [next in list] [prev in thread] [next in thread]