Closed mlang closed 3 years ago
The rest of the commit LGTM; the Nix test is failing but that's fine.
OK, import formatting (done with stylish-haskell) has been reverted. I basically just ran it because I was too lazy to manually find the places where to insert new imports such that they are sorted.
I was hoping to do a similar change (cursor) for ListOfMails, however, it appears there is a problem with where focus is, which I'd love to talk to you about. As I understand the code, focus is moved around when Up/Down are pressed in MailView, but ListOfMails does not have focus. So the simple check (ListOfMails == ^focusedViewWidget s) does not return True in MailView. I find the focus management of purebred a little confusing. Maybe you could advice on how to do a similar change to ListOfMails. ListOfThreads was easy, since the focus is indeed reported on ListOfThreads. However, MailView seems to keep the focus on ScrollingMailView, but the up/down keypresses are still rerouted to ListOfMails. In a sense, it would be easier if it were the other way around: Keep focus in ListOfMails, and reroute scrolling commands to the ScrollingMailView. So, any advice on putting a (invisible) cursor on the currently selected ListOfMails item?
OK, import formatting (done with stylish-haskell) has been reverted. I basically just ran it because I was too lazy to manually find the places where to insert new imports such that they are sorted. I was hoping to do a similar change (cursor) for ListOfMails, however, it appears there is a problem with where focus is, which I'd love to talk to you about. As I understand the code, focus is moved around when Up/Down are pressed in MailView, but ListOfMails does not have focus. So the simple check (ListOfMails == ^focusedViewWidget s) does not return True in MailView. I find the focus management of purebred a little confusing. Maybe you could advice on how to do a similar change to ListOfMails. ListOfThreads was easy, since the focus is indeed reported on ListOfThreads. However, MailView seems to keep the focus on ScrollingMailView, but the up/down keypresses are still rerouted to ListOfMails. In a sense, it would be easier if it were the other way around: Keep focus in ListOfMails, and reroute scrolling commands to the ScrollingMailView. So, any advice on putting a (invisible) cursor on the currently selected ListOfMails item?
I think this is just a historic reason on how it was built, rather then a conscious choice.
I actually need to ask since I don't know how accessibility works in a terminal. Where ever the cursor is positioned, the screen reader will read this section? So for MailView
it would be useful to read the selected entry and then the actual mail? It would probably be good to file an issue and we discuss this there?
One small nit from hlint:
src/UI/Index/Main.hs:23:1-40: Warning: Use fewer imports
Found:
import Brick.Types ( Padding(..), Widget )
import Brick.Types ( Location(..) )
Perhaps:
import Brick.Types ( Padding(..), Widget, Location(..) )
1 hint
and we can merge :)
@mlang can you please squash your undo formatting commit into the preceding commit?
@mlang alternatively, if @romanofski is happy with the change I can do the squash and push myself.
Yeah and address the small hlint
nit. Either way...
Commit: https://github.com/purebred-mua/purebred/commit/a457b2d986a527312033966c80059580b26eb64f . Waiting for CI results. If good, I'll push it and close this PR.
CI passed: https://github.com/purebred-mua/purebred/runs/3458958069 .
Pushed a457b2d986a527312033966c80059580b26eb64f to master
.
Closing this PR.
@mlang big thanks for contributing!
This is for the benefit of screen readers which use the cursor position as the primary focus indicator.