[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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic