Bug 82200

Summary: Home, End, Page Up and Page Down keys should work for the email list view.
Product: [Unmaintained] kmail Reporter: Mivz <mivz>
Component: keys and menusAssignee: kdepim bugs <kdepim-bugs>
Status: RESOLVED DUPLICATE    
Severity: wishlist CC: bjoern, Dexter.Filmore, krystof.zacek, robert, vapier, webmaster
Priority: NOR    
Version: 1.6.2   
Target Milestone: ---   
Platform: Gentoo Packages   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Mivz 2004-05-25 20:56:11 UTC
Version:           1.6.2 (using KDE KDE 3.2.2)
Installed from:    Gentoo Packages
Compiler:          gcc 3.3.2 20031218 Gentoo Linux 3.3.2-r5, propolice-3.3-7
OS:                Linux

At the moment people can onley scroll 1 msg at the time whit the keyboard.
I think it is important that at least the home and end buttons should work, like they work for the message it self (when selected).
Page Up and Down currentley scroll the message when the list is selected, but they should scroll the list. (for scanning long lists of email) The up and down keys (currentley not functioning) can be used to scroll the email if desierd.
I make this conclusion based on the fact that I know a lot of people scrolling throug long lists of emails and I know a few people who write email longer then twice the screen height.
Comment 1 Mivz 2004-06-04 12:33:27 UTC
I have seen there are more issues about the message navigation. Maybe it is an ide e to make it configurable. The thing about reading mail (processing input) is that it is a real analog task, which requires a configurable human input to optimize for different people. 
A good mail program to me is a fast inforation processor, how fast it works is determent bij the view and controls.
Comment 2 Tom Albers 2004-07-31 00:02:58 UTC
*** Bug 37085 has been marked as a duplicate of this bug. ***
Comment 3 Tom Albers 2004-07-31 00:06:51 UTC
*** Bug 76627 has been marked as a duplicate of this bug. ***
Comment 4 Tom Albers 2004-07-31 00:08:34 UTC
*** Bug 58202 has been marked as a duplicate of this bug. ***
Comment 5 ricardo 2005-01-25 03:42:03 UTC
The use of keys would be a good improvement.
Comment 6 ricardo 2005-01-25 03:42:33 UTC
*** This bug has been confirmed by popular vote. ***
Comment 7 Petre Kronn 2005-01-27 01:38:16 UTC
This key feature should be a nice improvement. When you are writing is more intuitive to use the keys to go around the mails.
Comment 8 Dexter Filmore 2005-02-05 15:24:35 UTC
Agree, all nav keys should go to the focused section.
PLUS: switching sections should be done by <tab>, and it shouldn't do anything else: tab cycle: search-folders-messagelist-messages.
or even better, leave out messages, all one needs to do in messages is scroll up and down, and here it would be better if there were global keys for that section only (yes, i know, this would be an exception to the "all nav keys should go to the focused section" idea, but I think one exception can be handled). Sylpheed for example uses Return/Backspace for that which took me about 3 seconds to adapt to it.
Or even better: make key shortcut entries for "scroll up/down"
Comment 9 w.posche 2006-10-22 21:14:59 UTC
Using the down button should actually mark the next mail. Right now only the left-right buttons work to navigate. But the mails are ordered above and below each other not to the left or the right.

The current behaviour actually does not make sense at all. If I want to go to the next message that is below the current one, I will press the arrow down key, not the arrow right key.
Comment 10 Ingo Klöcker 2006-10-24 23:37:04 UTC
Re #9: Since KDE 3.5.4 the shortcuts for Next/Previous message can be changed from Right/Left to whatever you want.
Comment 11 Bassio 2008-06-02 02:01:30 UTC
True, confirmed see here http://bugs.kde.org/show_bug.cgi?id=86627
Same issue.

And I repeat the comment I posted over there:

I find this rt-lt extremely non-intuitive and completely uncalled-for. And I am a new KDE user.
I beg the usability team to re-regard the issue again.
A simple 'follow the focus' approach will be most accessible to most users. A visual marker can be worked out to inform the user 
Comment 12 Björn Ruberg 2010-02-06 21:37:39 UTC
*** Bug 184486 has been marked as a duplicate of this bug. ***
Comment 13 Björn Ruberg 2010-08-06 20:42:50 UTC

*** This bug has been marked as a duplicate of bug 245866 ***