From kde-core-devel Thu Oct 31 18:50:56 2002 From: Malte Starostik Date: Thu, 31 Oct 2002 18:50:56 +0000 To: kde-core-devel Subject: Re: Back to the clipboard, part II. X-MARC-Message: https://marc.info/?l=kde-core-devel&m=103609034403826 Am Donnerstag, 31. Oktober 2002 15:33 schrieb Havoc Pennington: > Lubos Lunak writes: > > I also tried with MS Windows. There's usually one selection per > > application, so the problems with unselecting usually don't happen > > (unless you do 'New Window' in IE, they it looks like two apps, but in > > fact it's only one, having only one selection). > > I would have expected the selection to be per-window or per-document, > it's sort of surprising that they don't do it that way. It is per window. See below > > Lineedits in config dialogs unselect as soon as they > > loose the focus. I also noted that selecting something in Notepad and > > selecting a lineedit in its config dialog doesn't unselect the > > edited text. > > This sounds like per-window though. > > Maybe it's one of those areas (like window placement) where Windows is > really inconsistent. ;-) It provides some sources for inconsistency indeed: The selection is per window, but most windows or rather controls hide the=20 selection when they lose focus. This applies to both single and multiline=20 text edits as well as things like list boxes, list view etc. which hide the= =20 selection mark by default. This behaviour can be turned off by modifying th= e=20 controls' styles, but not too many apps do so. This is where the main=20 inconsistency comes in IMHO. Plus, some text edits will select everything=20 when you tab into them, others will keep their current selection (which is= =20 then un-hidden again). OTOH, as Lubos said, the selection is only a visual highlighting which does= n't=20 do anything per se, it only shows what characters/items/objects an operatio= n=20 will copy, cut or modify in any way. No auto-copying, no paste on MMB (whic= h=20 is rather annoying BTW :-) =2DMalte