*** 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
Attachment:
signature.asc
Description: This is a digitally signed message part.
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<