Some of the issues have already been addressed, others are wishlist items

Created attachment 8914 [details]
action for opening the message window

This patch adds a new action, which opens the currently-selected message in a
new window. It is also bound by default to the Enter key.

This addresses issue #3 in comment #0. It does not include the action for Esc
dismissing the message window.

Personally, I think that Left/Right and Up/Down makes KMail a lot easier and
faster to use.

On Tuesday 04 January 2005 18:09, Thiago Macieira wrote:

> This patch adds a new action, which opens the currently-selected message in
> a new window. It is also bound by default to the Enter key.

Thiago, KMail HEAD already does this. :)

Till

> 1) Pressing up/down arrow in the message list should display previous/next
> message in the list by default. This is what EVERYBODY would expect. I know
> this one can be configured - but it should be default. Keep the Left/Right
> hack configurable for advanced users, if you like it.

I have to say that I would expect up and down to scroll the message being 
viewed as it's the dominant piece of information being displayed.

> Please suppress your ego and take a while to have look at what a normal
> mail program looks like: mozilla-thunderbird, Evolution, Outlook Express.
> Or take Konqueror and play with file list in detailed view using
> Up/Down/Shift/Home/End/Enter etc.

Wow...  Considering that you're not contributing in _any_ way except by 
complaining, that's quite a statement...

Thanks Till.

It means my patch is now redundant. I didn't catch it because there were no conflicts.

OK, maybe I used too harsh language. But, please distinguish complaining from a user feedback. If I would think Kmail is a hopeless piece of crap, I would not bother to think about it, register and file reports. Don't you think, such feedback is also a kind of contribution?

To the comment #4:
Round and round: The Left/Right arrow behavior should not be default since it does not correspond to normal user's expectation. But, off-course lets have it there as an option for advanced users.

I don't know what a user expects who uses an e-mail application for the very first times.
But I know that KMail's way of handling keybord navigation is very fast. It's definitely consistent and documented, easy to learn and extremly usefull for high volume e-mail accounts. (I'm using mozilla in parallel, so I know what I'm talking about.)
Don't most of the users use the mouse anyway?

On Wednesday 05 January 2005 01:33, Krystof Zacek wrote:
..
> The problem: KMail ignores standards of keyboard navigation and KDE HIG
> guidelines:

The KDE HIG ignores the standard KMail shortcuts? I guess the KDE HIG needs 
more work then.

<cut same old arguments I've heard a dozen times before>

> take a while to have look at what a normal 
> mail program looks like: mozilla-thunderbird,

Terribly slow, no thanks.

> Evolution,

I remember it was quite slow also, but my memory is vague.

> Outlook Express.  

Excellent, as good as KMail. (At least the older version of express). Actually 
uses the same keys as KMail.

I quite like what I've heard about keyboard handling in the latest Outlook 
however. With up/down changing the current item in the headers and alt-up, 
alt-down scrolling the reader window. Unfortunately that would be a rude 
change though so no hurry from my point of view.

Don.

*** Bug 96973 has been marked as a duplicate of this bug. ***

I specially miss the ESC key to close messages quickly. I also found the behaviour of the navigation keys a bit weird, specially because it seems that the select next and prev are hardwired to shift up and down, but I use the mouse most of the time, so I don't really mind. However, a configurable quick close key would make me really happy.

On Thursday 20 January 2005 11:16, Ignacio CastaXXo wrote:
> I specially miss the ESC key to close messages quickly.

That's been added to HEAD. KDE 3.4 will contain this.

> The Left/Right arrow behavior should 
> not be default since it does not 
> correspond to normal user's expectation

When I first used KMail, I was pleasently surprised by this behavior. It only took me a few minutes to get used to it, now I can't see reading my email without it :) Please keep it as-is.

Well, you were lucky to find it. I didn't find it, and started to send a bug report, which teached me that many others have encountered this and also thought it a bug, and that I can use the right and left keys to move up and down. I am sure that there are many others who are still using the mouse and grunting.

I agree - the current behaviour is better than what was before it. The problem is that it is not intuitive, and so it should be left as a non-default option, for advanced users to find.

On kde-usability list somebody posted an article about what is considered intuitive or not. The author stated, that there is no such thing as this or that behaviour being intuitive, and the other not being. The trick is, that the user has to be given little hints in order to pick up a behaviour. If these hints are given, the current up/down left/right issue would be considered intuitive. So, either one gives the user a tour where s/he can learn that behaviour, or one thinks of little hints.

There are these boxes with hints, yet most people I know just turn them off, so a tour would have to be better than that. If navigation is supposed to be crucial, the tour could display that bit as default and have the other topics on the right, as in the settings window.

Little hints could be to display a line at the top of the message-preview, or as some people do not like it, at the top/bottom of the header-list that states the up/down left/right functionality, including some icons and a close button. If the latter one is pressed, the bar disappears forever, in order not to annoy people who already know about it.

*** Bug 102123 has been marked as a duplicate of this bug. ***

About comment #14
Sorry but for this issue we are in an *objective* field. The only "natural" way to scroll through a vertical list when the list is selected (in KMail case, mail pane is selected) *is* to use vertical keys and only them. How could be horizontal key intuitive for a vertical scrolling? It is no sense at all.

Could there not be a compromise here? - When the e-mail view pane is selected (focused), allow it to be scrolled using the vertical arrow keys, and when the e-mail list pane is selected (focused) allow it to be scrolled using the vertical arrow keys.

I'd really like KMail to get past this, because I would really like it to be used.

Is it less "natural", as you call it, to scroll a vertical text by up/down than scroll a vertical list by up/down? What keys would you consider "natural" for text, if you opened the message on its own? So, what you request is that users use e.g. left/right when viewing a text in the preview-pane, but up/down, when viewing it on its own? This would not be consistent within the app.

As there are two vertical-objects, there is no perfect solution, yet one might argue that you want to go to the _next_ message, which is consitent with right-arrow (at least for the west). Yet again, there is not best solution.
I like the one-handed navigation, so CTRL+DOWN to scroll the text or the list would not be an option for me. Yet scrolling the text by left/right is not perfect either, is it?

Working with focus is not a solution from my point of view, as the user would have to always click/use TAB, which is more work than just learning once that left/right does x, up/down does y.

I've been watching this discussion and I have to say that I like the 
kmail way. I switched to thunderbird a while ago, because of problems 
with kmail, and I found it very annoying to find that when I pressed 
down I got the next message instead of the message scrolling down.

I think the argument that the horizontal arrows might be considered as 
representing next/previous is entirely valid, as this is exactly how my 
brain came to think of it.

If the argument that because kmail's way is different to most other mail 
apps is going to put people off at the first try, then maybe we could 
have a semi-discreet message appearing during the first few days of use 
informing the user that they can flick through their message list with 
the forward(next) arrow and back(previous) arrow?

This way people that wouldn't even think about those keys would at least 
be told that they exist.

Just an idea

Sorry I've just read comment #14 which basically suggests the same idea.

@Segedunum, comment 17:

This is in no way meant to be flip, but having followed kmail development for a couple of years and having seen this rehashed many times already, there is IMHO no way that is will be implemented anytime soon by the current maintainers. The only way you will get this is by hacking/having it hacked yourself. Even then, a patch will most likely only be accepted if the current bindings are preserved, by e.g. having different profiles as mentioned above.

What I'm saying here is: If you want/need this, your best bet is to get hacking (or maybe http://kontact.kde.org/shopping/sanders.php can do something for you). But just saying 'if we don't have this I'm not going to roll out' does not impress anybody.

Finally: "You can have my left/right keys when you pry them out of my dead, cold hands".

> If you want/need this, your best bet is to get hacking (or maybe
> http://kontact.kde.org/shopping/sanders.php can do something for you).

This is an extremely simple bit of feedback that is simple to implement. You take bounties to their extreme and you have something that is a heck of a lot more expensive than proprietary software.

> But just saying 'if we don't have this I'm not going to roll out' does not
> impress anybody.

I'm afraid not reading doesn't impress me either. I've given you a usage pattern, and the way in which the vast majority of users go about reading their e-mail in many organisations.

> Finally: "You can have my left/right keys when you pry them out of my dead,
> cold hands".

Then please, don't ever talk to anyone about furthering the usage of KMail/Kontact, and in particular, trying to get businesses and organisations to adopt it. Make sure it is kept a private project.

> This is an extremely simple bit of feedback that is simple to implement. You > take bounties to their extreme and you have something that is a heck of a
> lot more expensive than proprietary software.

OK, let's not turn this into a flamewar, but let me say this:
1. I am not a kmail developer. As I said, I *follow* development. I read the mailinglist.
2. I give you *suggestions* on how to solve your problem.
3. You seem to misunderstand the concept of free software. The idea is that it is free because everybody commits in their own way, be it by developing, documenting, bug reporting, or even paying (in the form of cold hard cash or infrastructure). You are not entitled to anything, least of all free ('gratis') features. Up to now, you have not contributed anything, except a bunch of empty threats about how you are not going to roll out until this wish is implemented. As I mentioned before, threats like those will not get you your feature earlier, *contributing* does.
4. Regarding my 'cold, dead, hands' statement: That was not meant as a put-down of the way *you* think it should work. I think switchable binding profiles would be a good idea. I just wanted to make clear that a lot of established users are really happy with the way it works now, and that that is the reason that simple, easy fix that you envision will never be applied to kmail CVS. You are of course free to apply it to your local source tree.

> OK, let's not turn this into a flamewar

I'm certainly not going to lose sleep over it.

> 2. I give you *suggestions* on how to solve your problem.

No I'm sorry, you haven't. It isn't just my problem but countless others, and it isn't a very complex thing to fix either.

> 3. You seem to misunderstand the concept of free software.

No, I haven't. I want to use free software, and I'm furthering it's cause by trying to use it in a serious manner. However, this is an extremely simple basic concept I've described there that just cannot be grasped by anyone. I'm not demanding that 156 open get fixed tomorrow, just something really simple that will quite obviously further KMail and Kontact's adoption.

> The idea is that it is free because everybody commits in their own way, be it
> by developing, documenting, bug reporting, or even paying (in the form of
> cold hard cash or infrastructure).

Please don't use that as a barrier. I will remind you and others of it the next time you tout free and open software being used in business and organisational environments.

> You are not entitled to anything, least of all free ('gratis') features.

I know I'm not. I've described a very simple usability problem with KMail, and it won't get fixed. Fine. I will use Thunderbird on Windows, and probably Outlook for groupworking, and I won't lose any sleep about it. In the long run, it's Kontact, KMail and KDE's loss I'm afraid.

> Up to now, you have not contributed anything

I'm contributing by using the software, or wanting to, and if all goes well I will probably contribute a heck of a lot more.

> except a bunch of empty threats about how you are not going to roll out until
> this wish is implemented.

I never said that - I mentioned that it would, from the experience given, harm Kontact, KMail and KDE's adoption in such circumstances. Read please.

> threats like those will not get you your feature earlier, *contributing*
> does.

And how will I contribute to a bug that quite clearly will not get fixed? At least from the feedback I've seen so far, anyway.

> Regarding my 'cold, dead, hands' statement: That was not meant as a put-down
> of the way *you* think it should work.

I never saw it as such. I'm trying to help on a really simple problem here - that's all. I'm not going to lose sleep over it. Ultimately it will be KDE, KMail's and open source software's loss in the long-run.

> I just wanted to make clear that a lot of established users are really happy
> with the way it works now

As I, and even Matthias Ettrich in the past on this subject, have pointed out, they are not established users. The people who I work with are, and as it stands, they simple won't use it. If attracting those users isn't a goal of KMail, Kontact and KDE as a whole then that's fine - just say so. If it is, then someone should at least try and give some reasoned feedback on why this can't, won't and shouldn't be adopted.

According to Don Sanders above, he likes Outlook's keyboard handling! It may get changed, it may not. If there is a consensus to change by some version then let us know!

Since I have been following this conversation, I have not heard anyone mention 
that you can use the scroll wheel on your mouse to scroll either pane, at 
will, and without clicking inside of either pane.

I have been a network admin/user support/etc. guy for many, many years now. 
The vast majority of users I have ever interacted with have always used the 
mouse as their primary means of navigation in any program. Furthermore, 
hardly anyone uses the scroll wheel. They always click and drag the scroll 
bar.

I know this is a conversation about *keyboard* navigation, but the claim that 
the current keyboard navigation scheme renders the program "unusable" is 
utter nonsense, IMHO. 

By the way, I prefer the keyboard navigation scheme just the way it is now, 
thank you :) It only took me a few minutes to get used to it, now I would 
never want to be without it.

I actually filed a bug that is a duplicate of this one, and the person who has filed this bug has used exactly the same language as I did - without me seeing this bug first!

> Since I have been following this conversation, I have not heard anyone
> mention that you can use the scroll wheel on your mouse to scroll either
> pane, at will, and without clicking inside of either pane.

Not the issue. The issue is the behaviour by default of scrolling through a vertical list with horizontal arrow keys - something which the vast majority of users don't pick up and won't pick up because it is logically flawed.

> The vast majority of users I have ever interacted with have always used the 
> mouse as their primary means of navigation in any program.

Please watch these users come in in the mornings, and then watch how they scroll through their mail before deciding what to do about each one. There is a more detailed usage pattern for this described above and on other bug reports.

> I know this is a conversation about *keyboard* navigation, but the claim that 
> the current keyboard navigation scheme renders the program "unusable" is 
> utter nonsense, IMHO.

Have you seen how most users perform the above task? I'm afraid it does render the program unusable, and as such KMail and Kontact cannot be recommended in the vast majority of cases for a lot of users.

> By the way, I prefer the keyboard navigation scheme just the way it is now, 
> thank you :)

It isn't just about you I'm afraid - that is, if you would like KMail/Kontact to be used by a wide variety of users out there.

> It only took me a few minutes to get used to it, now I would never want to be
> without it.

Unfortunately it is totally illogical. How many applications, KDE or not, do you see that require scrolling through a vertical list with horizontal arrow keys? None. I've brought this up before, and unfortunately, when you mention that anywhere everyone seems to clam up tight as tight as a drum.

Funny - you get to the point where KMail/Kontact is quite complete as an application, and yet people persist on defending current behaviour that is quite simply not logical outside a very small clique of KMail users and developers.

On Thursday March 24 2005 11:22, Segedunum wrote:

> Please watch these users come in in the mornings, and then watch how they
> scroll through their mail before deciding what to do about each one. There
> is a more detailed usage pattern for this described above and on other bug
> reports.


I observed three users this morning, for about an hour each. I told them I was 
studying the speed of their connections to the network (yes, I know that's 
total BS, but they dont know any better :), so there was no chance of the 
user being influenced by what I told them I was observing.

Two of the three clicked the scroll bar with the mouse and dragged it, even 
though they have wheel mice. The third used the wheel, but still clicked in 
each pane when he wanted to scroll that pane. I am not sure if it's relevant 
or not, but the one who used the scroll wheel is more of an "advanced" user 
than the other two.

> Have you seen how most users perform the above task? 


Yes.

> I'm afraid it does render the program unusable, and 
> as such KMail and Kontact cannot be recommended 
> in the vast majority of cases for a lot of users. 


Have you observed users reading their mail? Do you have any figures or 
observations to substantiate these claims?

> It isn't just about you I'm afraid 


I'm also afraid that it's not just about you :) The *vast* majority of people 
I know, who use kmail, use the keyboard navigation shortcuts, and quite 
happily.

> How many applications, KDE or not,
> do you see that require scrolling through a vertical list with horizontal
> arrow keys? None. 


Exactly right, none. Nor does kmail. There are two other options (scroll bar, 
mouse wheel), and three if you configure it. You can use the Configure 
Shortcuts dialog box to configure kmail to go to the next message with 
up/down.

> I've brought this up before, and unfortunately, when you 
> mention that anywhere everyone seems to clam up tight as tight as a drum.


I'm not sure what you mean by that, other than a flame attempt. Is that really 
necessary?

> Two of the three clicked the scroll bar with the mouse and dragged it, even 
> though they have wheel mice. The third used the wheel, but still clicked in 
> each pane when he wanted to scroll that pane. I am not sure if it's relevant 
> or not, but the one who used the scroll wheel is more of an "advanced" user 
> than the other two.

Not all that relevant, but it pretty much makes the case for change really. Did you see any users who actually tried to use the arrow keys (or indeed any keys to navigate around their e-mails), or work out about using their horizontal arrow keys when their vertical arrow keys didn't work? If they couldn't work it out then they *will* simply resort to using the mouse or whatever means they can to do this.

Did you ask them at all?

> Yes.

I'm afraid you've not looked deeply enough at it. See above.

> The *vast* majority of people I know, who use kmail, use the keyboard
> navigation shortcuts, and quite  happily.

I'm sorry, but you are not the vast majority of users. Try doing this with people who are not exclusive KDE or Kontact users or programmers - you know, the sort of people who KDE and Kontact are trying to attract (allegedly), and why Matthias Ettrich started KDE in the first place.

> Exactly right, none. Nor does kmail.

What????!!!!! You're telling me that KMail doesn't fly in the face of logic and all other applications by not allowing a user to use their vertical arrow keys to move through a vertical list of items. Are people making this up or something do you think? I'm afraid you're seeing things that aren't there.

> There are two other options (scroll bar, mouse wheel), and three if you
> configure it. You can use the Configure Shortcuts dialog box to configure
> kmail to go to the next message with up/down.

Again, that's not relevant and you're avoiding the issue. We're talking about arrow keys in particular (and key navigation of mails in general) here.

You're also talking about 'configuring shortcuts' and 'configuring KMail', ergo, you *are not* an ordinary user and if you're asking people to do this neither are they.

> I'm not sure what you mean by that, other than a flame attempt. Is that
> really necessary?

I'm afraid the above isn't flaming, although you may like it to be. When you see people travelling in completely the opposite direction to where logic is heading it's probably going to come out like that I'm afraid.

Okay, it has been said in another comment, but to make it clear and obvious 
and to let this fruitless discussion end:

The developers (actually the people that currently contribute to KMail's 
sources) consider the current key bindings usefull. Additionally, they 
consider the step to learn the meaning for two key bindings to move in the 
header list a small one for any person.

I can say at least for me that I won't work on another set of key bindings 
because I want to spend my time on other things which I consider more usefull 
or needed. (This is about my spare time and subject to change if money comes 
into play.) However I wouldn't be against the inclusion of a patch which 
provides set of key bindings.
I think this will hold for the other people involved into KMail's development 
as well, but to make sure one has to ask them.

The conclusion is: Everybody who contributes by using KMail can use it as it 
is or come up with a patch to change the situation.

PS. I still don't get it where the contribution is in a simple usage. I've 
never heard about any people contributing to e.g. MS-DOS by having used it.

> Okay, it has been said in another comment, but to make it clear and obvious
> and to let this fruitless discussion end:

Given what's been presented and why I don't see why it should be fruitless at all, but there you go.

> The developers (actually the people that currently contribute to KMail's
> sources) consider the current key bindings usefull.

Well, if that's true then they're in a minority. However, if that's what they want then that's fine - it depends who their target is.

> Additionally, they consider the step to learn the meaning for two key bindings
> to move in the header list a small one for any person.

That isn't reflected in practice with users in the field, and there is ample evidence and reasoning above as to why. You may find that out eventually.

> I can say at least for me that I won't work on another set of key bindings
> because I want to spend my time on other things which I consider more usefull
> or needed.

It wouldn't mean getting rid of the current keybindings - probably just modifying the defaults. However, even doing that can be extremely controversial as happened when Konsole was moved to the system menu.

> I can say at least for me that I won't work on another set of key bindings
> because I want to spend my time on other things which I consider more usefull
> or needed. (This is about my spare time and subject to change if money comes
> into play.)

If this were a large, complicated and fundamental change to KMail, and a bit of a grey area to boot, then I would completely agree. However, it's not any of those things.

> The conclusion is: Everybody who contributes by using KMail can use it as it
> is or come up with a patch to change the situation.

That's fine, but to know if a patch is actually going to be applied and accepted (and used by default, which is important in this case) you have to argue reasonably why the current behaviour doesn't work and why it should change and get a consensus on it. I don't think that's been reached, so I see little point in anyone submitting a patch for this because some people seem to want to protect this until grim death.

If I'm wrong, correct me, and give some indication: "Yes, we think this should be changed, and we're open to it, but we don't have any time to work on it at the moment so we're open to any patches."

> PS. I still don't get it where the contribution is in a simple usage. I've
> never heard about any people contributing to e.g. MS-DOS by having used it.

People 'using' MS-DOS (and more importantly, Microsoft making people actually want to use it and then Windows) put Microsoft where they are today ;).

However, if you don't want people using KMail then that's absolutely fine - ultimately it's up to the people doing the lion's share of the development. I'm certainly not bothered about it, but if the usage of KMail/Kontact in business, organisational and government settings is going to be discussed at aKademy this year I see very little point in actually doing that to be honest.

> If this were a large, complicated and fundamental change to KMail, and a bit
> of a grey area to boot, then I would completely agree. However, it's not any
> of those things.

Actually, it is. The point is that the bindings in kmail are focusless, i.e. they work the same way whichever panel (folder, headers, or preview) has focus. I assume that your preferred bindings would break that, since you would like up/down to move the current message when the headers have focus, and the previewed message when the preview has focus.

(As an aside: once you're used to this behavior, getting back to thunderbird or outlook is just as infuriating as kmail's setup is to you, since all of a sudden you need to actively manage your keyboardfocus in order to navigate)

This makes a patch more than just new bindings. What is needed what mentioned before: a new binding profile, which would allow you to switch between the focusless current setup and the focused setup you prefer. This is not as trivial as just changing bindings.

> If I'm wrong, correct me, and give some indication: "Yes, we think this
> should be changed, and we're open to it, but we don't have any time to work
> on it at the moment so we're open to any patches." 
 
I think Andreas made this clear ("However I wouldn't be against the inclusion of a patch which  provides set of key bindings."). This is of course assuming that said patch meets certain quality standards, a goal that is easily achieved by having the patch reviewed on kmail-devel, and that focusless bindings stay possible.

> Actually, it is. The point is that the bindings in kmail are focusless, i.e. 
> they work the same way whichever panel (folder, headers, or preview) has 
> focus. I assume that your preferred bindings would break that, since you would
> like up/down to move the current message when the headers have focus, and the 
> previewed message when the preview has focus.

No actually, I would prefer it if it could stay focusless - at the very least *most* of the time - as that would be quite useful. It's finding a logical way to do it for most users out there in the world.

It's just one aspect of the keybindings that I've found to be a real problem in all of this. As for other keybindings etc. above in this bug report, I think they'd have to be thought through a bit more. There is various references to 'normal programs' in the description above. I don't want a 100% Outlook clone, but just to work for something logical for most people. I've certainly never had a problem with the colours of unread e-mails, and I think there'd need to be some usability evidence as to why this is bad.

> This is of course assuming that said patch meets certain quality standards, a 
> goal that is easily achieved by having the patch reviewed on kmail-devel, and 
> that focusless bindings stay possible.

Thanks very much. The message for people who want this then is to get coding and make some patches. However, would there be a room to change the *default* set of keybindings whilst leaving the existing ones alone for people to turn on? That's what this would ultimately entail.

I just tried Kmail and was overall very happily surprised. I love the way I can navigate without having to move focus between the tree pane, the list pane and the preview pane, but I still do think the keyboard navigation has some issues (yes, the default bindings are probably very efficient, but yes, they are also probably unintuitive and contrary to what a user used to other software expect). Let's see if I can contribute something to the debate.

First, since it seems to be impossible to reach consensus as to which keybindings are the best, what about presenting the following options the first time a user starts Kmail?

* "I'm used to mainstream mail readers and would like the key bindings I expect, thank you."

* "Please let me use the default revolutionary key bindings that let me read my mail so much faster (once I learn them)."

Second, is it possible to agree that with enough actions to bind keys to,  everyone can get the behaviour he or she wants?

Even if focus-independent navigation is very nice I still expect to be able touse the arrow keys in the usual way (up to move selection and focus up, down to move down, left to move to the parent node or collapse subtree, right to expand subtree or move to the first child, shift+arrows to extend the selection, and ctrl+arrows to move the focus - like in all apps, even other KDE apps). But what I find is that some keys are forcibly bound to the message pane and can't be unbound! That's unacceptable! (Also, I have to press some keys twice or thrice to get any action, but that's another bug.)

I think the following actions are needed for everyone to be able to customize Kmail according to his or her taste:

- Go to next/previous message, expanding and descending into threads
- Go to next/previous visible message, not expanding any threads
- Go to next/previous thread
- Go to next/previous unread message
- Go to next/previous folder
- Go to next/previous unread folder
* All of the above, except just move the focus
- Scroll preview pane up/down (one line)
- Scroll preview pane up/down (one page)
- Scroll preview pane down (one page); when at bottom jump to next unread message (Who can live without that one!?)
* All other currently available actions
* Possibly more

Sorry, the space key does indeed have the dual effect of scrolling down, then jumping to the next unread message. I wasn't testing well enough.

To clarify, I believe that the navigation keys should, unless explicitly configured otherwise by the user, have their normal functions, i.e. to move around in the currently focused widget. On the other hand, one should be able to perform most, if not all, navigation *without leaving* the preview pane. It should probably even be focused automatically in certain situations, such as when hitting space in the mail list to select the currently focused, but not selected, mail.

(If one *uses* the preview pane, that is. As someone pointed out earlier, it's completely ridiculous that I can't even use the up and down arrows when the preview pane is hidden.)

I don't mind if the left and right arrows jump to the previous or next mail when I am in the preview pane, but please leave them alone otherwise.

To make it easier to jump between the three panes, on those occasions when you need to, I would expect to be able to use for example ctrl+tab or F6 to jump between them without having to step over all hyperlinks.

*** Bug 121541 has been marked as a duplicate of this bug. ***

One though about being intuitive (GUI) -- there is such thing, but through previous experience. And KMail is the only program which uses such bizarre keyboard navigation. Thus it is not intuitive.
I constantly try to press arrow-right in aMule just because I quit KMail just a second before.

I think there KMail will stay not user friendly until the same arrow-down will scroll down the messages list and the message itself -- this is what users all around the world are used to (if you don't agree show me the case when in order to go up you press left). Of course such dual behaviour is not possible -- so... panes switching but not necessarily with "tab" style. Rather press "1" to activate message pane, "2" for messages list pane. This way one key could have several meanings which are not in conflict, switching would be really fast.

The "smart" behaviour could be added too -- for example autoswitch to message pane after X seconds. I mean activating it. It would be also consistent with "mark message read...".

As you outlined yourself, there are two "down actions" in kmail's default GUI, i.e. preview not hidden. So it seems obvious that you have to look for a distinction. What one finds is that there is acutally a next/previous and a up/down action.

There is no denying that going through a list can be described as well by "going to the next/previous item" as by "go to the "upper/lower item". So, in one pane you need to go next, in the other down in order to have two seperate actions. Kmail does exactly that, "go to the next item in the list", "scroll down the preview". Next, i.e. forward, at least in all countries that use left to right writing, is right, hence cursor-right, to go forward to the next item in a list. The best solution if you have two lists.

Anything involving Tab is not efficient because it needs more keystrokes and you have to either use your second hand, or move the one you use, so it is not really an improvement. It might save the user some minutes on the first time one uses kmail, but your suggestions would cost a lot more time if the user continues to use kmail, so it is not an improvemnt, neither in terms of usability nor efficiency.

Any "after x seconds" is too complicated and time-consuming too. I would get very annoyed if I would have to wait x seconds, if I could just use up/down, left/right to do the same without any delay.

So I do not see your point in "improving" kmail. Forget about any comparison with applications that do not have the trouble of having two "down/next"-actions. You are comparing apples and pears if you compare amule with kmail. They might both use lists but are none the less different kind of fruits.

The time and ease of kmails navigation outweigh the millisecond a human brain needs to remember that it is different from an application without panes, especially if one uses it frequently, which one can expect in case of an email-reader. Changing anything would cost the user time and effort every time one wants to scroll/jump to the next item and hence decrease usability. Usability does not mean that users must not learn anything, it is about mediating the best way to handle the application.

So since kmail's navigation is the most efficient keyboard-navigation already, there is only an issue of mediating it the first time a user uses kmail, but that is another issue and addressed in another bug.

> So
> it seems obvious that you have to look for a distinction. 

In keys? Not necessarily. Visual distinction can help.

> Anything involving Tab is not efficient because it needs more
> keystrokes and you have to either use your second hand, or move the
> one you use, so it is not really an improvement. 

I agree with that but for other reason -- there are three panes and when you have to go to the third in the list it would be too complicated (ctrl+tab, tab). But 1, 2, 3 fits here quite well.
Similar solution you can find in Forte Agent. And it works _well_.

> Any "after x seconds" is too complicated and time-consuming too. I
> would get very annoyed if I would have to wait x seconds, if I
> could just use up/down, left/right to do the same without any
> delay.

Misunderstading.
a) it would be an extra option
b) it would work in different way -- _IF_ you wait and message get "read" you will be switch to message pane
ad.b) if you want to switch without waiting you press "2"

> So I do not see your point in "improving" kmail. Forget about any
> comparison with applications that do not have the trouble of having
> two "down/next"-actions. You are comparing apples and pears if you
> compare amule with kmail.

I don't compare them. I am telling you that I use various software. See below.

> The time and ease of kmails navigation outweigh the millisecond a
> human brain needs to remember that it is different from an
> application without panes, especially if one uses it frequently,
> which one can expect in case of an email- reader. 

Completely not true. The facts are these -- I use KMail for years now, I use Forte Agent, Konqueror, etc. for years too.

And _ALL THE TIME_ only KMail interface makes a confusion. Understand me correctly -- I am not saying that when I first saw Kmail then... I am saying that I had problems using it before and I have problems _now_. 

Unification. Application should behave in uniform manner. aMule does that, Konqueror does that, Forte Agent, gFtp, name any app. Only Kmail does not. It is not good -- you should not introduce double standards and say "oh, it is app X, please redefine your thinking".

No matter how long you use KMail, it could be 50 years, it does not matter, if you launch three apps (KMail + 2 other) and you will use the simultanously your brain will trick you -- either you will try to press "down" in KMail to get to the next message or you press "right" in the other apps to get to next item (amule/kmail case). There is no chance to avoid it (unless you pretend to work :-D). And this is  __THE WHOLE POINT__ (I am not shouting, but I like to stress that here lies the problem -- KMail __is not compatible__ with KDE, with the rest of the world).

And/or... provide single pane view (like Forte Agent):
https://bugs.kde.org/show_bug.cgi?id=141880

Please, take a look at Forte Agent -- it is really good example how to handle layout&keyboard with three panes.

Shorter version :-)
__IF__ kmail would be a isolated app, no KDE, no anything, then, yes, use this layout which fits KMail best. Use "v" for next item, use F5 as "escape", ctrl+z as paste, ctrl+a as undo. As long as it would be best productivity it is ok.

But there is only one problem -- kmail is not single island. There is KDE, there are whole other apps. Single productivity factor does not matter anymore, only overall. And uniform UI is the key, and kmail violates it.

In other words Kmail _lowers_ overall productivity thanks to all those switches "kmail-world, kde-world, kmail-world, kde-world". 

So tell me then, which other KDE application has three panes and uses a better, i.e. you only need one hand and no movement of the arm, navigation.

If you have problems of acting upon context, i.e. three panes looking different and hence triggering a different behaviour then a simple list or a two panes application, i.e. if you cannot associate your behaviour to two different and very distinct looking applications, then that is certainly not kmail's fault. Context is always the key for remembering things and acting, so why should it be different here?

Remebering cursor-up is always up does simply not work for three panes. Just remember: three panes: next=right, i.e. remember the context. It works quite well for me. One day computers may be able to get the context from your eyes, i.e. know what list you are looking at and hence applying the keys to that list, but since then, the human brain will have to remember the context and act upon it.

If there would be tab or anything else, you would have to remember one extra-information as well, i.e. three-panes: use tab, or 1,2,3 or whatever you suggest, so you do not improve anything but just change the extra thing you have to remember and associate with the context.

There can never be a unified navigation for single and multiple pane application because up/down only works for one of them without adding some extra (hence less efficient) key. All applications with just one pane should and are unified, i.e. up/down, yet kmail has to behave differently for one of the lists, because it has three panes by default, it is a three-paned island in a sea of single-paned islands, apples and pears. Unify one pane applications and unify three pane applications, but not all of them, because it is impossible.

123 is not that good either in increasing usability as it involves moving the arm, or having to use another hand, so no improvement here.

> If you have problems of acting upon context, i.e. three panes looking
> different and hence triggering a different behaviour then a simple list or a
> two panes application, i.e. if you cannot associate your behaviour to two
> different and very distinct looking applications, then that is certainly not
> kmail's fault. 

Kdevelop, Kate, Konqueror, Forte Agent, K3b uses more than one pane and ALL of them uses arrow down key for, hmmm, let me think, going down. Oh, my, how on earth is this possible? Apage satanas. 

I give up, sorry -- you want to prove something not provable, fine, but talk to psychologists first, maybe they will explain better than me, that context switching __takes time__. And uniform UI __saves time__ (since I work not for fun, I am trying to save time and achieve maximum productivity). Of course, it is human nature fault, not KMail, and KMail is simply designed for creatures far better than lousy human beings.

It is really sad that KMail, one of main KDE app, takes usability as some kind of nonsense. Unfortunately it is not the first case among KDE apps. 

EOT.

> Kdevelop, Kate, Konqueror, Forte Agent, K3b uses more than one pane and ALL
> of them uses arrow down key for, hmmm, let me think, going down. Oh, my,
> how on earth is this possible? Apage satanas.


You do not get it, they do not use arrow down for down, they use X + arrow 
down for down, e.g. Tab + down. If not they could just handle one pane. Apart 
from that: apples and pears: email is handled differently than developing 
code, or burning a DVD in regard to pane usage. For example, reading email 
involves no typing of text, so the "text-pane" has a different status in 
kmail compared to kdevelop, k3b does not even have a "text-pane". Apples and 
pears.

Further, in those apps the user has to look at the context (screen) in order 
to see which pane is focused and, if it is not the intended one, use some key 
to change to the one s/he wants to act upon. In case of tab that can mean two 
keystrokes + time to notice which pane is focused. and in terms of usability, 
even if the active pane was framed in a colour, what about colourblind 
people?

In kmail it just takes time to notice that one uses kmail instead of amule and 
you have separate keys for separate panes, no ambiguity or "signal focus" 
issues.

Instead of switching (Tab) kmail uses other keys which demand less hand/arm 
movement.

>  You do not get it, they do not use arrow down for down, they use X + arrow 
> down for down, e.g. Tab + down. 

GOOD! Better solution that currently implemented in Kmail. And all those apps behaves __the same__. "Good" for the second time.

> Instead of switching (Tab) kmail uses other keys which demand less hand/arm 
> movement. 

...which takes more time. Unless you have supernatural skills like 0 seconds per context switch.

Would it be possible to introduce dual UI for KMail -- I see there are absolute fans :-) of current KMail UI (like you), but I see there are a lot of people who would use "normal" UI -- like any other app in KDE.

PS. 

> Instead of switching (Tab) kmail uses other keys which demand less hand/arm 
>  movement. 

Answer it to yourself -- what is the shorcut for (three pane view):
* next folder
* the last message in the list
* first message
* next page of messages
* previous page of folders
* the last folder
* starts selecting text from the message

With uniform UI I would have no problems answering those questions -- because answers are "trivial" (the same as in Konqueror, FA, etc etc etc.)

PS2. One more though -- dual UI is doable in a gentle way -- it is sufficient to allow assigning the same key. Which leads to ambiguity, and this would be solved but checking what pane is active. 
So one solution would fit users used to KDE apps UI, and the same solution would suit you (you would define next message as right, next portion of message as down and there would be no ambiguity -- so no change here really).

PS3 :-) 
I made small survey how other email clients work. Before I proceed what made the current GUI desktop so successful? Graphic appeal? Colors? Or maybe (quote from some Polish magazine) that when you know _one_ app you know all of them.
Very true (except for KMail).

Now -- three panes layout (folders/message list/message content):
* balsa -- down for down
* thunderbird -- down for down
* claws -- down for down
* evolution -- down for down
* forte agent (newsreader, win) -- down for down
* eudora (win) -- (afair) down for down
* kmail -- right for down (sic!)

So maybe Kmail _is_ an isolated island after all and what makes it so hard to fit in KDE world is not keyboard layout but ego. And such discussion and false-proving that KMail makes the whole KDE experience better (more productive, more intuitive) simply pushes users away.

Maciej, nobody stated that the current keyboard navigation in KMail has to 
stay the only mode. In fact, if you would provide a way to optionally switch 
KMail to a standard keyboard navigation mode, it would certainly be accepted.

So, instead of wasting your's and other's time with writing countless comments 
about something which has been stated many times before, you better hack down 
something which will give you fame from all who cannot remember some simple 
keystrokes beyond the usual KDE "defaults".

> nobody stated that the current keyboard navigation in KMail has to 
> stay the only mode. In fact, if you would provide a way to optionally switch 
> KMail to a standard keyboard navigation mode, it would certainly be
> accepted. 

Andreas, thanks for your comment -- great to hear that (although, I will be not able to help in writing code for another year).
 

The simple fact of the matter is that no other application in existence makes you move through a vertical listbox by using horizontal arrow keys. It is a problem, and is a fairly large reason why either Evolution or Thunderbird gets used in a lot of cases. We're not talking about an 'optional switch' thing here - this is a discussion about what the default should be. If people then want to switch to something somewhat less straightforward that allows them to keep their hand on the keyboard, then so be it.

The original message also raises a good point about making out unread messages. Using a colour isn't a problem per se, but other mail clients use bold as a way of distinguishing unread messages. If we're just using colour to distinguish this, then suppose a user is colour blind to some degree?

I'd be interested to hear what a 'usability' expert would make of this, what their recommendation might be and what the thinking behind this was when the standard guidelines of keyboard navigation were dispensed with.

On Monday 19 February 2007 22:37, Segedunum wrote:
> The simple fact of the matter is that no other application in
> existence makes you move through a vertical listbox by using horizontal
> arrow keys. It is a problem, and is a fairly large reason why either
> Evolution or Thunderbird gets used in a lot of cases.


Funny, I always assumed that most users use the mouse for handling their 
email, so how could this issue concern a lot of cases? In my case I never 
used keyboard-navigation in TBird or other clients because hitting Tab is 
just too annoying.

Windows is used most often, does that make it the best solution? Just because 
the majority of apps uses Tab, does not mean it is the best solution.

> We're not talking 
> about an 'optional switch' thing here - this is a discussion about what the
> default should be. If people then want to switch to something somewhat less
> straightforward that allows them to keep their hand on the keyboard, then
> so be it.


What association exactly does Tab have with switching panes? If cursor-right 
is not straigth forward for "next", Tab certainly is not for changing panes. 
So if down is taken and you need an extra key Tab is not the obvious choice 
because it is best suited for navigation, but just because most other 
email-cleints use Tab. So it is just what you are used to, not the obvious. 
If you want to make GUIs like most people are used to, just copy Outlook 
Express, anything else is not familiar to most potential users. If you do not 
do that I can always argue that whatever differs cannot the best solution, 
because most people are used to something else. Does that make sense to you?

However it seems that there is a claim that the only thing that matter is 
mediating the functionality of the GUI, via hints, which as a result makes 
the GUI intuitive. I think the article was mentioned on the usability-list, 
so you might want to search google for it.

> The original message also raises a good point about making out unread
> messages. Using a colour isn't a problem per se, but other mail clients use
> bold as a way of distinguishing unread messages. If we're just using colour
> to distinguish this, then suppose a user is colour blind to some degree?


True, but another issue.

> Windows is used most often, does that make it the best solution? Just because
> the majority of apps uses Tab, does not mean it is the best solution.

No. The issue here is that having to use horizontal arrow keys is just wrong on every level in using keyboard navigation on a listbox, it is not in any HIG guidelines you'll ever see, no other application does it and more importantly, horizontal is not vertical.

> So it is just what you are used to, not the obvious.

Horizontal is not vertical in most peoples' worlds.

> So it is just what you are used to, not the obvious. If you want to make GUIs
> like most people are used to, just copy Outlook Express, anything else is not
> familiar to most potential users.

Being like, or not like, Outlook or any other client is not the issue here. See above for the issue distilled into one sentence.

> ...whatever differs cannot the best solution, because most people are used to
> something else. Does that make sense to you?

No, because it's rubbish, but I suppose that was the intention. C'est la vie. See the first sentence in this post for a concise sentence on the problem.

Again, I'd like to see a usability person's input on this, just so we get more of a balanced view and for any other ideas someone can come up with.

> No. The issue here is that having to use horizontal arrow keys is just
> wrong on every level in using keyboard navigation on a listbox, it is not
> in any HIG guidelines you'll ever see, no other application does it and
> more importantly, horizontal is not vertical.


You got a very limitied view. You interpret it as down, which is valid, but 
next item is as valid and next is not bound to down at all. Just think about 
the mouse-wheel. Move the cursor to a horizontal scroll-bar or slider and 
scroll down, what happens, does it go up? There you go.

> > So it is just what you are used to, not the obvious. If you want to make
> > GUIs like most people are used to, just copy Outlook Express, anything
> > else is not familiar to most potential users.
>
> Being like, or not like, Outlook or any other client is not the issue here.
> See above for the issue distilled into one sentence.


Not really. Please explain further how your destilled sentence proves that tab 
is the best key for navigation and not just the most often used. Without tab 
or any other extra key your "solution" is not working. You cannot demand 
up/down without another key in the package. Nobody is denying that for a 
single pane application up/down is the best solution, yet that is just not 
the case for kmail. So what is the argument for using Tab? any other 
than "most other apps use it?".

> > ...whatever differs cannot the best solution, because most people are
> > used to something else. Does that make sense to you?
>
> No, because it's rubbish, but I suppose that was the intention. C'est la
> vie. See the first sentence in this post for a concise sentence on the
> problem.
>
> Again, I'd like to see a usability person's input on this, just so we get
> more of a balanced view and for any other ideas someone can come up with.


Have you searched for the article I mentioned?

A usability person's input is irrelevant unless he's actually performed a study with a significant amount of test persons.

The fact that this wish has merely 49 votes clearly shows that this is an issue only for a handful of people. (Well, 3 isn't even a handful.)

We, the developers, are fully aware of the problems some people have with KMail's unorthodox keyboard navigation and we'll make it configurable as soon as we have dealt with the 1000+ more important issues.

> The fact that this wish has merely 49 votes clearly shows that this is an
> issue only for a handful of people. 

It means that 49 votes survived last voting for each person thanks to bug in Bugzilla. 
 

> You got a very limitied view.

Well, horizontal is not vertical. It doesn't get more basic than that.

> Move the cursor to a horizontal scroll-bar or slider and scroll down, what 
> happens, does it go up? There you go.

You're stirring around trying to find something, with no success. The fact that you can use a vertical mouse wheel to scroll a horizontal scroll bar is of limited use for most because of the differences in direction, but obviously has nothing to do with this.

If I put a vertical listbox on a screen, and then gave you a mouse with a wheel positioned *horizontally* to scroll through it, do you think that would work for a lot of people?

> Not really. Please explain further how your destilled sentence proves that 
> tab is the best key for navigation and not just the most often used.

Whether you use tabbing or panes or not is irrelevant. Using horizontal keyboard keys to navigate through a vertical listbox simply goes against every set uf usability guidelines you will ever see. Why? Because it's the complete *opposite* of what you're doing and what's on screen.

> Without tab or any other extra key your "solution" is not working.

How is it *working* now?

> So what is the argument for using Tab? any other than "most other apps use 
> it?".

Whether you use tabbing or not to switch panes, or come up with another layout, isn't really relevant. What *is* relevant is that the direction in which a user is going on the keyboard does not reflect the on screen direction in any way. Quite frankly, if you use panes, changing focus is far better than using totally illogical navigation which goes in completely the opposite direction to what the user actually sees.

KMail's keyboard navigation for mail browsing is an interesting experiment, but it has failed for that fundamental reason.

> A usability person's input is irrelevant unless he's actually performed a 
> study with a significant amount of test persons.

I'm curious. Was there a usability study performed to get the current behaviour, do you know?

Translation: Let's try and ask for something that most people won't be able to do, and hope it goes away. Sorry, but that's the way it looks.

Would you like to see a study? The problem I have with that is that it will take a bit of effort to set up, and it probably won't be listened to. Besides, all you have to do is read through a set of interface guidelines anywhere on navigation. It's pretty basic stuff, and not rocket science.

> The fact that this wish has merely 49 votes clearly shows that this is an 
> issue only for a handful of people.

And Bugzilla voting is somehow meaningful now, especially since you're talking about a study, with a 'significant number of test people' above?

> are fully aware of the problems some people have with KMail's unorthodox 
> keyboard navigation

That's interesting. Do you know why you used the word 'unorthodox' there?

> and we'll make it configurable

Well, this bug isn't about making it configurable from what it is now. It's a discussion about what KMail's logical default should be - and make it configurable from there to something illogical (but moderately useful) should people so wish.

> as soon as we have dealt with the 1000+ more important issues.

You can't get much more important than a major reason for people not wanting to use an application - not as many as there should be, anyway. I realise that this 'feature' in KMail has come to be a pretty sensitive area for some people in terms of change.

> If I put a vertical listbox on a screen, and then gave you a mouse with a
> wheel positioned *horizontally* to scroll through it, do you think that
> would work for a lot of people?


Exactly that is the problem you keep denying. There is not one list but two 
and you cannot move the "mouse", so I would be happy to have two wheels and 
use one for up/down and the other for next/previous instead of having to use 
another hand.

> > Not really. Please explain further how your destilled sentence proves
> > that tab is the best key for navigation and not just the most often used.
>
> Whether you use tabbing or panes or not is irrelevant. 


? Without tabbing you would not be able to use down for preview as well as the 
message-list, which is why this whole issue exists. One key, two actions.

> Using horizontal 
> keyboard keys to navigate through a vertical listbox simply goes against
> every set uf usability guidelines you will ever see. Why? Because it's the
> complete *opposite* of what you're doing and what's on screen.


Ok. how can the opposite of down be right, but anyway. Imagine your computer 
could understand your speech. Now you sit in front of your kmail and what do 
you tell the computer if you want to go the _next_ email in the list. Do you 
say "go down", or "list down" or do you just say _next email_? If you want to 
scroll the text, what do you say? "Next line" could be an option of course, 
but most people want to scroll more than one line, so I guess one would 
say "scroll text down".

Kmails navigation mimics this logic.

> > Without tab or any other extra key your "solution" is not working.
>
> How is it *working* now?


Sorry, but if you claim that navigation does not work because you cannot 
remember two keys, that is just pathetic.

> > So what is the argument for using Tab? any other than "most other apps
> > use it?".
>
> Whether you use tabbing or not to switch panes, or come up with another
> layout, isn't really relevant. What *is* relevant is that the direction in
> which a user is going on the keyboard does not reflect the on screen
> direction in any way.


There is not only the direction on the screen, but the way you think about 
your "command" to the computer. Would you force people to tell their computer 
to "go down" instead of  "next email" if speech-control was possible?

> Quite frankly, if you use panes, changing focus is 
> far better than using totally illogical navigation which goes in completely
> the opposite direction to what the user actually sees.


It is less efficient, even a one handed can navigate the list and preview 
right now, without moving the hand.

> KMail's keyboard navigation for mail browsing is an interesting experiment,
> but it has failed for that fundamental reason.


Since most people use the mouse, it has not failed for the majority. I can 
claim that most people that use kmail's keyboard navigation think in terms of 
next rather than down and you cannot disprove it, as I cannot disprove the 
opposite.

> It's a discussion about what KMail's logical default should be

Let's not stretch this (bug) report too far :-)) -- there is currently no alternative, so it is hard to choose which one should be default, right?

Anyway, in this report it is surprising that the basic principles of UI are violated and some try to convice the rest of us it is for greater good.
a) the principle of the least surprise (not only related to computers)
b) the principle of the uniform look&feel 

ad.b) if "all" apps would use double click as "close the app" no matter how ridiculous it could be, there should be no exception "nah, we violate it because..."

I can accept the notion of Left/Right as Next/Previous, but I personally prefer navigating through my mail with Space and the keys above it (N, B, the keys to the right of M etc.). Interestingly, my solution *also* allows me to use only one hand to perform this basic task.

As I explained in comment #33 ff, I sometimes want to move around quickly in the message list, perhaps selecting a bunch of messages to move to a different folder or mark as spam. That task becomes exceedingly difficult when one has to use a multitude of modifier keys to direct ones input to the desired window pane. Using Tab to move focus once in a while is a good investment. But as I also wrote in comment #33 ff, it is a problem that Tab stops on every hyperlink in the preview pane as well as in the quick search bar. Allowing Ctrl+Tab and F6 to move directly between the three panes would be an improvement.

Nevertheless, some people might be satisfied with the default key bindings, but I had to patch the source code since Up/Down were hardcoded to scrolling the preview pane.

Another thing I wrote in comment #33 ff is that Kmail could very well have its present behaviour *as long as* the preview pane is active, and it never has to become inactive unless the user chooses to move the focus! Thus it is possible to get the best of both worlds!

*** Bug 150664 has been marked as a duplicate of this bug. ***

*** Bug 159493 has been marked as a duplicate of this bug. ***

SVN commit 803951 by tmcguire:

Some more porting to KDE4:

- Use QHostInfo instead of KNetwork
- Q3Accel->KAction
- many QAction->KAction, so the default shortcut appears correct
  again in the configure shortcuts dialog

The port of Q3Accel to KAction has the side effect that the shortcut
to scroll the message up/down can now be configured.

CCBUG:96301


 M  +2 -4      configuredialog.cpp  
 M  +0 -35     headerlistquicksearch.cpp  
 M  +0 -6      headerlistquicksearch.h  
 M  +1 -1      kmfilteraction.cpp  
 M  +1 -1      kmfilteraction.h  
 M  +0 -3      kmfolderdialog.cpp  
 M  +110 -136  kmmainwidget.cpp  
 M  +2 -10     kmmainwidget.h  
 M  +2 -3      kmmessage.cpp  
 M  +5 -15     kmreadermainwin.cpp  
 M  +1 -1      kmreadermainwin.h  
 M  +27 -0     kmreaderwin.cpp  
 M  +14 -13    kmreaderwin.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=803951

*** Bug 167307 has been marked as a duplicate of this bug. ***

*** Bug 86627 has been marked as a duplicate of this bug. ***

*** Bug 100974 has been marked as a duplicate of this bug. ***

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.

Instead of creating a new feature request, please confirm here if the wishlist is still valid for kmail2.