Hello team,
I spent quite a few hours back in 2006 "scratching my own itch" in the roundcube code. I haven't had much time to work on it since then, but I happen to have some time at the moment to dedicate to the project.
I just submitted a pull request that will make "control-click" and "control-arrow-key" behave more like a native application. One thing that has always bothered my about the roundcube layout is that there's no way to know which message in the list has the "focus" in cases where the focus is separate from the selected message. For instance if you select a message, and then CTRL-click that same message, it will be unselected, but it still has the focus, because if you then click the down arrow it will select the next message.
The css "outline" attribute would work for this, but there are some inconsistencies with where exactly each browser places the outline - and IE (including IE10) does not support the outline-offset attribute at all, which means that the outline doesn't work very well in IE (no surprise).
To see what I mean, you can insert the following style into styles.css:
.records-table tr.focused {
outline:1px dotted black;
outline-offset: -1px;
}
I'd appreciate any thoughts on the issue!
-Charles McNulty
On 10/23/2013 11:10 PM, Charles McNulty wrote:
I'd appreciate any thoughts on the issue!
Well, without your "fix" there is no problem with focus. I don't see a use-case for such functionality. What you want to do with focused, but not selected message?
On 2013-10-24 02:37, A.L.E.C wrote:
On 10/23/2013 11:10 PM, Charles McNulty wrote:
I'd appreciate any thoughts on the issue!
Well, without your "fix" there is no problem with focus. I don't see a use-case for such functionality. What you want to do with focused, but not selected message?
Hi, thanks for the comments! First the ctrl-arrowkey behavior is just to bring it in line with native desktop behavior. For instance, if you are in a multiple dropdown select (in any browser), and you use the ctrl-arrow keys, it won't select the options that are focused. Using ctrl-arrow keys to select messages is inconsistent behavior outside of any changes to the CSS, which is why I put it in it's own pull request.
Now, in terms of use-case - I agree that it really needs to be paired with spacebar-to-select functionality so that one could select a message to be deleted, ctrl-arrow-down a few times to the next message they want to delete, tap the spacebar, and then when they've selected the messages they want to delete, press the delete key - no mouse needed.
The downside of using the spacebar is that some people expect to be able to use spacebar to page-down. However it looks like at least in Chrome and Firefox, spacebar-to-pagedown is not working anyway in RC, so perhaps it's time to implement spacebar-to-select. I'll work on a pull request for that today - should be pretty easy.
-Charles
On 10/24/2013 04:29 PM, Charles McNulty wrote:
The downside of using the spacebar is that some people expect to be able to use spacebar to page-down. However it looks like at least in Chrome and Firefox, spacebar-to-pagedown is not working anyway in RC, so perhaps it's time to implement spacebar-to-select. I'll work on a pull request for that today - should be pretty easy.
I've never used spacebar-to-select feature, but with this functionality it makes sense.
OK, I'm going to submit a pull to add left/right arrow support for expanding/collapsing threads (which brings it in line with how Outlook handles threads - plus/minus will also be supported), and *drop* support for toggling threads with the spacebar. Instead spacebar will be used to select messages, so that one could use exclusively the keyboard for selecting and deleting multiple non-sequential messages. I don't know how many people use the spacebar for toggling threads, but it seems like the ability to select messages with the keyboard is more useful, and also more standard.
-Charles
On 2013-10-24 11:21, A.L.E.C wrote:
On 10/24/2013 04:29 PM, Charles McNulty wrote:
The downside of using the spacebar is that some people expect to be able to use spacebar to page-down. However it looks like at least in Chrome and Firefox, spacebar-to-pagedown is not working anyway in RC, so perhaps it's time to implement spacebar-to-select. I'll work on a pull request for that today - should be pretty easy.
I've never used spacebar-to-select feature, but with this functionality it makes sense.
On Wed, Oct 23, 2013 at 11:10 PM, Charles McNulty charles@charlesmcnulty.com wrote:
Hello team,
Hello Charles
I spent quite a few hours back in 2006 "scratching my own itch" in the roundcube code. I haven't had much time to work on it since then, but I happen to have some time at the moment to dedicate to the project.
Welcome back!
If you want us to get you commit rights to our github repository, just let us know. You previously contributed good work to Roundcube and we're happy to get you back. Or if you're comfortable with sending pull requests, we'll gladly accept them of course.
I just submitted a pull request that will make "control-click" and "control-arrow-key" behave more like a native application. One thing that has always bothered my about the roundcube layout is that there's no way to know which message in the list has the "focus" in cases where the focus is separate from the selected message. For instance if you select a message, and then CTRL-click that same message, it will be unselected, but it still has the focus, because if you then click the down arrow it will select the next message.
Keyboard navigation per se isn't really implemented in Roundcube and the UI likely doesn't behave correctly. That's actually on the roadmap somewhere...
The css "outline" attribute would work for this, but there are some inconsistencies with where exactly each browser places the outline - and IE (including IE10) does not support the outline-offset attribute at all, which means that the outline doesn't work very well in IE (no surprise).
To see what I mean, you can insert the following style into styles.css:
.records-table tr.focused { outline:1px dotted black; outline-offset: -1px; }
I didn't have the time to review that yet. But I'll also have a look into this.
Kind regards, Thomas
On 10/23/2013 11:10 PM, Charles McNulty wrote:
To see what I mean, you can insert the following style into styles.css:
.records-table tr.focused { outline:1px dotted black; outline-offset: -1px; }
Works for me in FF, Chrome and Opera. However,
- It looks good for unselected messages. I'm not sure I like when
'selected' message has the outline, that's why 2. We should consider using font-style:italic or maybe better different background-color instead outline, but be aware of selected+focused style. 3. Messages list in classic skin does not use .records-table class. So, some more changes needed.
On 2013-10-30 07:52, A.L.E.C wrote:
On 10/23/2013 11:10 PM, Charles McNulty wrote:
To see what I mean, you can insert the following style into styles.css:
.records-table tr.focused { outline:1px dotted black; outline-offset: -1px; }Works for me in FF, Chrome and Opera. However,
- It looks good for unselected messages. I'm not sure I like when
'selected' message has the outline, that's why
Agreed completely the browsers are inconsistent when applying the outline to a TR, and of course not even IE10 supports outline-offset.
- We should consider using font-style:italic or maybe better different
background-color instead outline, but be aware of selected+focused style.
Agreed - it's not ideal, but I think it's the best option given browser implementation of outline. Personally, I think a different background color would be better than an italicized font.
- Messages list in classic skin does not use .records-table class. So,
some more changes needed.
Good catch, it looks like CSS could use either #messagelist or .messagelist both of which are shared across skins. Or records-table could be applied to the table in the default skin.
-
A.L.E.C -
Charles McNulty -
Thomas Bruederli