TUI regression for screen readers

[hasufell]

I got an email from a blind user:

Hi,

I'm reporting this ghcup bug to you, as I saw that you have been lately the
person doing ghcup development (based on git logs), and I am unable to submit
an issue through GitLab's web interface.

I am a blind user and have been very happy about GHCUp's support for the
invisible cursor, that points to the selected meny entry in ghcup tui.

I saw that Mario Lang has provided this support some years ago.

I have upgraded to GHCUp 0.1.22.0 and now the cursor is gone. While GHCUp tui
is shown, the cursor stays at the lower-right corner of the screen, and it is
very hard for a braille display user to detect which menu entry is focused.

While I'm writing to you, there are few other things I would like to see
improved in GHCUp, so I'll report them as well.

1. While GHCUp is installing tools, it switches the terminal from alternate
   screen to the primary one. Some terminals, however, don't have an alternate
   screen. One such terminal in use is the Linux virtual console. On Linux
   console the installation command output overlaps with the TUI, which looks
   bad.

It would be possible to fix this by moving the cursor to the bottom of the
screen and printing a newline before exiting the alternate screen. This way
the output would work normally both in terminals that support alternate
screens, and the ones which don't.

2. Home/end/PgUp/PgDn keys don't have bindings in GHCUp tui. They would move
   to the first/last item in the menu, or scroll one page backward/forward
   respectively.

Thank you very much for your work with GHCUp and in the Haskell community in general!

---

@lsmor

[hasufell]

Related: #4

[hasufell]

@lsmor

this is the fix for your current PR:

diff --git a/lib-tui/GHCup/Brick/Widgets/Navigation.hs b/lib-tui/GHCup/Brick/Widgets/Navigation.hs
index 77de48e..0685bf4 100644
--- a/lib-tui/GHCup/Brick/Widgets/Navigation.hs
+++ b/lib-tui/GHCup/Brick/Widgets/Navigation.hs
@@ -36,6 +36,8 @@ import Brick
       (<+>),
       (<=>))
 import qualified Brick
+import           Brick.Widgets.Core ( putCursor )
+import           Brick.Types ( Location(..) )
 import           Brick.Widgets.Border ( hBorder, borderWithLabel)
 import           Brick.Widgets.Border.Style ( unicode )
 import           Brick.Widgets.Center ( center )
@@ -100,7 +102,8 @@ draw dimAttrs section_list
           | elem Latest lTag' && not lInstalled =
               Brick.withAttr Attributes.hoorayAttr
           | otherwise = id
-    in  hooray $ dim
+        active = if b then putCursor Common.AllTools (Location (0,0)) else id
+    in  hooray $ active $ dim
           (   marks
           <+> Brick.padLeft (Pad 2)
                ( minHSize 6

I believe... however, we probably need to do the same for the new popup windows, so that screenreaders know where we are. I'm not sure how to test all this.

[hasufell]

Ah, we can use showCursor instead of putCursor to see where it is during development. That will also allow us tho check it for all the popups.

[lsmor]

I've pushed the fix you propose and also the same fix for the new popups. I have tried to use ubuntu's screen reader to test it, but honestly I don't know how to use it (It seems to not read a thing in my screen...)

By the way

Home/end/PgUp/PgDn keys don't have bindings in GHCUp tui. They would move
to the first/last item in the menu, or scroll one page backward/forward
respectively.

this can be done for sure. Is it worth?