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

List:       kde-devel
Subject:    "Select All" on text input
From:       FiNeX <finex () finex ! org>
Date:       2008-06-28 8:11:33
Message-ID: 200806281011.37105.finex () finex ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


*** from FiNeX & Maciej ***

*** to kde-devels ***


There are two reports about ctrl+a (select all) feature on bugzilla:
  http://bugs.kde.org/show_bug.cgi?id=150512
  http://bugs.kde.org/show_bug.cgi?id=150511
one for Kmail, and the other for Kate. 

The problem is about the different behaviours of ctrl+a (select-all) in 
different applications. It doesn't do the same thing on all apps: 
in some apps the caret is moved at the end, in some other it doesn't move.
If it doesn't move, if you try to modify the selection (just done with 
select-all) you could have differents behaviours.

Example:
10 lines of text, caret at the begin of the 5th. ctrl+a (select all), the 
caret is still on the 5th line; shift+up:
case 1) the selection is lost, and the 4th line is selected.
case 2) the selection change, only the first three lines are selected.

Quite contrary when you select all by explicitly moving caret -- ctrl+home, 
ctrl+shift+end -- then you'll ever be able to deselect few last 
rows/characters. If you start from the end you can exclude few first 
rows/characters.

So, CTRL+A will select all, after you could have different 
behavior, "ctrl+home, ctrl+shift+end" you are sure that what you'll do after 
will be ever the same on all apps.

Try for example the kmail composer (or the korganizer editor) and kate/kwrite, 
or one simple textbox in a webform, or the knotes text editor, or, kjots.

Textboxes (inherited from Qt), kate part editor, the richtexteditor... them 
should behave the same.



Maciej had even thought to a possible solution:

  «The idea is not to break current ctrl+a behaviour but add those 
capabilities in such way, they user could get advantages of 
ctrl+home... shortcuts.
  How this can be done -- well, the suggestion is to wait for the user 
after ctrl+a. If user does something still in selection mode, like 
shift+up place caret at the end and then execute the shortcut (if 
shift+down, at the beginning). If user starts to navigate right away 
(like pressing right arrow) -- preserve current behaviour.

  So you can think of it as delayed caret placement -- caret is 
virtually in three places at once, and _next_ user decision set the 
caret for good in one of those.

  UI penalty is zero, UI benefit is saving several keystrokes and 
having much more flexible selection behaviour. The saving is maybe 
not that much for edit-boxes but for KMail is rather significant (I 
bumped into this problem "select all except these last paragraphs" 
too often :-) ).»


At first sight it seems a stupid problem, instead, it is not: places used from 
users for type text should behave in the same manner.


Regards

FiNeX & Maciej :-)


P.S: We know that now the priority is 4.1, so, for the moment we've send this 
mail to this ML as "reminder", after 4.1 we'll remember about this again :-)

-- 
by FiNeX
http://www.finex.org
finex (@) finex (.) org
Linux Registered User #306523

["signature.asc" (application/pgp-signature)]

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


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