[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-21 13:41:09
[Download RAW message or body]

On Thursday 21 February 2002 02:38 am, Lubos Lunak wrote:
> On Wed 20. February 2002 23:13, Scott Wheeler wrote:

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

Ok, I'll make a patch.

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

Actually I just tried this in a few apps.  I can select something in KMail, 
Konq, KEdit and in a text box in the application that I'm working on all at 
the same time.  So, this might be why other widgets don't have the same 
problems that QLineEdit does--they don't do the same thing when something 
else is selected.  So again, my question is, what is *right*.  It seems that 
this should be the same for all Qt/KDE widgets.

> > 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).

Is there a way to tell which application owns the selection?  And of course 
this is a problem with what I mentioned above.  Widgets don't seem to 
deselect things when something is selected in another app.  This seems to be 
a pretty big consistency problem.

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