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

List:       kde-usability
Subject:    Re: Selection-to-Clipboard Inconsistencies
From:       "Jamethiel Knorth" <jamethknorth () hotmail ! com>
Date:       2004-06-06 15:55:11
Message-ID: BAY7-F10abtneqdGSyM0005d140 () hotmail ! com
[Download RAW message or body]

>From: Sébastien Laoût <sebastien.laout@tuxfamily.org>
>Date: Sun, 06 Jun 2004 15:34:21 +0200
>
>Hi,
>
>Several time ago, selecting a text in a QLineEdit was copiying this text
>to clipboard.
>But usually, when we activate such LineEdits, they sometimes select all
>the contents. It was very annoying.
>Now it seem to work better (don't know why : certainly because it
>doesn't copy :-) ).
>
>Yes : perhapse a copy when selecting by keyboard is a good thing.
>But do never copy text when they are autoselected by moving focus to
>lineEdits.
>Then it's more usable but become inconsistent (it is sensed to be the
>"Selection" clipboard and automaticaly selected texts and not copyed).

I'd been mulling over exactly this last night. Selections that are not 
implicit by the user probably should not count. So, if you were using IE and 
clicked once in the location bar, this would not change the selection, even 
though IE is set up to have all the text of the location bar selected when 
you click on it. Similarly, tabbing through a list of editable combo-boxes 
would not change the selection.

There needs to be a differentiation between explicit and implicit 
selections. If you select using shift (or whatever your selection key is) it 
is explicit. If it happens as a side-affect of something else, it is 
implicit.

>-*-
>
>The primary clipboard is pasted with MMB, so it requieres mouse.
>If you select text by keyboard, you have your hands on the keyboard.
>You then must move them to mouse to be able to paste.
>Would be good if a keystroke allow to paste MMB clipboard !
>So, yes, selections by keyboard could be productives : no need to move
>hands to the mouse (or perhapse what I've described is a multi
>clipboard, as klipper should work).

You're right, middle-mouse-button paste by keyboard would be great. It 
should just get added to the keyboard shortcut list in KDE, I suppose, 
although that means a lot of applications won't support it.

>-*-
>
>Lastly, Mozilla keyboard selection is quite annoying :
>Each time you release Shift and then continue to select, a new contents
>is pasted to clipboard.
>So, klipper is fullfilled by a lot of seemless selections (and klipper
>become useless) such as :
>- key
>- key to the
>- key to the extra credit
>- key to the extra credit question is in the user's
>- key to the extra credit question is in the user's right-handedness.

I had not known. However, I can't see how they were wrong. If more is added 
to the selection, it should be added to replace the previous selection. If 
there is a way to just edit a previous selection, I suppose that it what 
they should have done.

>-*-
>
>I also agree with Leo :
>
>Le sam 05/06/2004 à 21:41, Leo Savernik a écrit :
> > An example why keyboard selection should not affect the primary 
>selection is
> > this:
> >
> > You have an input field with loads of (unselected) text in it. You want 
>to
> > replace it with what is currently in your primary selection. But you 
>cannot
> > mmb paste it, as the text field is still full of crap. The text field 
>doesn't
> > provide a delete button (unlike konqueror's location bar).
> >
> > If keyboard selection does not overwrite the primary selection, you 
>simply
> > click into the input field, hit Ctrl+A, Del, and mmb paste. Four quick 
>steps.
> >
> > If keyboard selection *does* overwrite the primary selection, you have 
>to
> > delete every character manually (by del or backspace). Depending on how 
>much
> > crap is in there, this may take a long time.
>
> > For a real-world example that works this way, take Netscape Navigator's
> > location bar. Keyboard selection does replace the primary selection 
>there,
> > and if I want to mmb-paste an url into the bar, I have first to delete 
>every
> > single character. For long urls this takes an annoyingly long time.
>
>Howether, in that particular example, you can press Ctrl+U to play the
>same role as Konqueror [clear] button !
>Good to know (when the user know it).
>If you want to delete the end of the adress, place your cursor at the
>start and press Ctrl+Del.
>To delete from begin to cursor, it's Ctrl+Breakspace.
>So partial URLs can be pasted as well.
>
>But, you still need keyboard...
>AND those keystroke works in KDE also, but it delete word by word (the
>same as Shift+Right and then Del, or Shift+Left and then Del) so, for an
>entire paragraph the problem still here.
>
>
>-*-
>
>
>That was some clues, but I can't decide if keyboard selections should be
>copied or not...

I'm very uncertain as well. However, I am certain it should be consistent. 
And, since there are major tools doing it both ways, it's not gonna be an 
easier transition either direction. Mozilla and OpenOffice do it one way, Qt 
does it another, and GTK does it wrong. That's a ton of things to change no 
matter which way it goes.

Also, I noticed that the keyboard selection in Kate is broken as well. If 
you hold shift and move around, the selection goes to the primary selection 
buffer. However, if you select by word using ctrl+shift, it does not. That's 
just silly.

_________________________________________________________________
Is your PC infected? Get a FREE online computer virus scan from McAfee® 
Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]