Bug 150511 - composer: provide partially unselectable select-all selection
Summary: composer: provide partially unselectable select-all selection
Status: RESOLVED WAITINGFORINFO
Alias: None
Product: kmail
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: openSUSE Linux
: NOR wishlist
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-10-05 19:12 UTC by Maciej Pilichowski
Modified: 2012-08-19 00:25 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Maciej Pilichowski 2007-10-05 19:12:36 UTC
Version:            (using KDE KDE 3.5.7)
Installed from:    SuSE RPMs

In other words select-all is a little broken, because it should be 100% equivalent to:

ctrl+home
ctrl+shift+end

But unfortunately it isn't and thus you cannot (for example) unselect last rows after select-all.
Comment 1 FiNeX 2008-06-27 15:15:56 UTC
If I've understand right, this bug is no more reproducible.

(you're saying that after CTRL+A you cannot unselect the last rows, right?)
Comment 2 Maciej Pilichowski 2008-06-27 15:31:24 UTC
ctrl+a
shift+up

and you should get everything except for last row
Comment 3 FiNeX 2008-06-27 15:55:55 UTC
The behaviour depends from the caret: when you do CTRL+A the caret is not moved, instead doing ctrl+home and ctrl+shift+end the caret go to the end, so shift+up behave differently from where the caret is.

And this is right :-)
Comment 4 Maciej Pilichowski 2008-06-27 16:12:15 UTC
True, but why not add smart feature (I have feeling I proposed something like this for Kate already).

Note: if you would like to stay in selection mode after ctrl+a are there _any_ benefits of current fixed behaviour? None.

Here is the idea:
a) ctrl+a
b) following action still keeps the selection?
b.1) yes -> place caret on the fly at the end 
b.2) no -> ok, like today

This way you could have both worlds at the same time. UI penalty --> zero. Benefits --> yes, true and smart replacement of ctrl+home + shift+ctrl+end.

Ok, so reopening, because this is intention of this wish.
Comment 5 Maciej Pilichowski 2008-06-27 16:18:12 UTC
Good feeling :-))
http://bugs.kde.org/show_bug.cgi?id=150512
Comment 6 FiNeX 2008-06-27 16:42:37 UTC
Thanks for pointing me out the bug #150512.

You're right, the behaviour should be the same on all KDE apps.
Actually the kmail composer window use the same widget as korganizer editor.

Other editing places are the standard Qt textboxes and kate part.

It should be decided a common behaviour and applyed at least to:
1) kate part
2) textboxes
3) richtext editor used in kmail and korganizer

... it seems like not an easy task.
Comment 7 Myriam Schweingruber 2012-08-18 09:01:04 UTC
Thank you for your feature request. Kmail1 is currently unmaintained so we are closing all wishes. Please feel free to reopen a feature request for Kmail2 if it has not already been implemented.
Thank you for your understanding.
Comment 8 Luigi Toscano 2012-08-19 00:25:09 UTC
Instead of creating a new feature request, please confirm here if the wishlist is still valid for kmail2.