GNOME Bugzilla – Bug 80346
RFE: Reading mail with menu and keyboard
Last modified: 2004-12-22 21:47:04 UTC
There should be a 'View' option in the 'Message' menu to open the message window. This should be bound to Space, Enter or another keyboard shortcut. Presently the only way to read mail is by double-clicking with the mouse. (I used to use the preview pane, but no more for performance reasons).
I would elaborate the RFE: Indeed opening the e-mail itself is an extremely important but missing feature. There are more required key bindings like: up/down arrows for previous/next messages, which today (1.3.5) only move through the mailboxes, but not in the main window, or the Del key, which is not bounded in the main window. The generalized solution (and the more implementation-time consuming..) is to let the user bind keys to commands.
Created attachment 8289 [details] [review] Patch to add Message|Open and Message|Open next unread in balsa with keybindings O and space
Apologies for spam... marking as GNOMEVER2.3 so it appears on the official GNOME bug list :)
Updating.
Created attachment 32402 [details] Adds next and previous message to message window Keyboard commands are now available for all of the above. In the main window: P and up select the previous message N and down select the next message Ctrl+N selects the next unread message space or enter views the selected message In the message window: Ctrl+N selects the next unread message Ctrl+, and Ctrl+. select the various parts within the message The patch adds support for Next and Previous to the message window by means of menu items added to the Message menu (with keys N and P) and adds corresponding buttons to the toolbars. The normal Next and Previous icons are used for this, and new icons have been created for the Next part and Previous part buttons and menu items. The only issue with this patch is that the Next part and Previous part buttons are not disabled when the message only has one part. The Next message and Previous message toolbar and menu items disable when appropriate.
Created attachment 32411 [details] [review] additional patch The patch works very nicely! (The issue with sensitivity of next/previous part controls can be fixed with the this attachment.) The only debatable behavior I've seen is that when you hit `next message', the one displayed is `next' relative to what's currently selected in the message list, not the message currently displayed in the message window. You could argue that that's what the user wants, but I would also expect some users to be surprised! We *could* reselect the displayed message, but that might cause even more surprises...
Thanks Peter. I can only see that behaviour if the user has two message windows open. Then, it can call up the next message as selected by another window, which is indeed confusing. Is that what you are referring to? I've also realised the D and delete keys need to work in the message window as well, but I'll do that after the next/previous behaviour is sorted out.
What I saw was that if I open a message window, and then select a new message in the list (without necessarily popping up a new window), it's that message that determines what's `next' or `previous', not the one that's displayed in the message window. As I wrote, I don't see it as a killer, just worth discussing... As for D and Del--yes, it would be nice if they worked the same as in the main window. But it looks as if the message window is trying to be a "tear off" preview window. If that's the goal, is there a more general way to achieve it?
Okay, I see it now. My personal view is that it would make more sense to display the message after the one in the message window. I think that would be what people would expect and want. If not, they would go back to the main window. Because multiple message windows may be open, it might be best to leave the main window selection alone and not use it as a reference. Instead each message window would have its own position in the index. But the index position seems to be tied closely to the widget selection and I'm not sure how best to select a new message without altering the selection in the main window. Any ideas?
I agree--finding the next/previous/next-unread message relative to an arbitrary message should be part of the BalsaIndex api. Sadly, it isn't--and it will take some careful reorganization to fix it! The currently selected message plays a very distinguished role in the current code. Still, it *is* fixable...
Created attachment 32477 [details] Adds several accelerators and next/previous message to message window I think most would agree that reorganizing the API is best left until a development branch. Should a new bug be opened on that to track it? Maybe at some point, the code for the message menu can be made common to both the main and message windows. For now, I guess it is best to leave the behaviour as is. I've added in your patch, added a menu item with keyboard shortcut for the delete command, and added the Delete key accelerator. Trash/Delete already exists on the toolbar, so it isn't really adding any behaviour that doesn't already exist.
Re the api: I'm adding four functions to BalsaIndex for finding the next (etc.) message starting from an arbitrary message--no need to mess with the existing api. Re the UI: Everything looks good, except for the Delete key accelerator: in the main window, that's an alias for Ctrl+D, "toggle deleted flag", so having it here as an alias for D, "move to trash", could be confusing. You could argue that it should be an alias for "move to trash" in both windows, but that would change the existing behavior and would need an airing. I'll also add "next flagged" to the Message menu. Other: I'm uneasy about the possibility that the same message might be displayed in more than one message window. I haven't seen it cause a problem, but it makes me nervous! So I'm adding some code to avoid it, instead raising the existing window--that should meet the user's need, and just feels safer.
Oops, silly mistake. By all means remove the accelerator or implement "flag as delete" for the message window. I didn't intend to alter the beaviour.
Committed, without the accelerator, to cvs. Thanks for the work!
Tests out okay here. There's just two minor little things. It would be nice if the Next part and Previous part buttons were disabled on the last and first parts respectively. Secondly, after using N and P to move amongst the messages, pressing D to delete a message does not update the main window as usual. The message still shows in the main window list (with the trash icon) until I select it and then select another message. This does not happen when the selected message in the main window is the same as the message in the message window.
Thanks for testing! Re Next/previous part: agreed--I looked at that, and it's not easy to decide when we're at the last or first part! The code for switching parts is a bit murky... Re updating: agreed--that's fixable, but the best fix isn't clear. I'll let you know when we have something to test.
Cvs now contains code for managing the next/previous part controls, both in the message window and in the main window (which had the same problem). We're working on updating...
Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs. Filter on "SUN A11Y SPAM" to ignore.
Cvs now contains code for updating the message list in response to actions taken in the message window. I believe all the original issues have been addressed, at least in part. The Message menu still has no Open or Open Next Unread items, but space-bar activation of the GtkTreeView provides a keyboard method for viewing the message in a separate window. The menu is already unwieldy. Also, several key-bindings have been added over time since versions 1.3.x. I'm therefore resolving the bug as FIXED. If you feel that any issues remain, please reopen the bug, with comments or suggestions for the current version. Thanks for the active discussion!