Architecting my application

[erikd]

Hi, I am a reasonably experienced Haskell dev but I have never used Brick before.

I have an idea for a Brick app which will display a number of different views of what is basically tablular text data.

Basic needs are as follows:

• Data is read from a file which is updated periodically.
• The view of the data is changed every 15 seconds, in a round robin fashion.
• Keystrokes can cause switches from view to view immediately.

I hoping to get some pointers on how this should be architected. Links to appropriate Haddock docs appreciated.

[jtdaugherty]

Hi @erikd - out of curiosity, how familiar are you at this point with brick's design, particularly as it relates to how applications must interact with brick itself? For instance, have you read any of the user guide or looked at the demo programs?

[jtdaugherty]

Okay, great!

[erikd]

Thanks @jtdaugherty . The user guide plus the examples got me sorted out. I have my app rendering a single view of my data and responding to events as it should. All I need to do now is add the new data views.

Basically I needed to:

• Define my state struct.
• Define a BChan to supply data to the event handler which can then put it in state struct,
• Define my appDraw and appHandleEvent functions, Basically did not need the rest.

Thanks again.

[erikd]

One little problem I have is that I am using appChooseCursor = Brick.neverShowCursor and after I quit the program using Brick.halt the terminal that the program was run in also has no cursor. Its there a way to reset the terminal cursor after Brick.halt (I am using customMainWithDefaultVty)?

I know I can do it by running reset in the terminal but that's a bit of a pain.

[jtdaugherty]

What platform are you on? That sounds like a bug in the shutdown implementation in Vty. The neverShowCursor function is unrelated to shutdown behavior and restoring terminal state; neverShowCursor is just a selector for which Brick-rendered cursor gets placed at draw time.

[erikd]

i am on Linux.

[erikd]

For now, I have fixed the shutdown problem with:

  putStrLn ""
  clearScreen

With clearScreen coming from System.Console.ANSI. Unfortunately this only fixes part of the problem. It does not fix the missing cursor.

Also tried setSGR [ Reset ] but that did not help.

The only thing that actually worked is callProcess "reset" [].

[jtdaugherty]

What terminal emulator are you using, and what version of vty-unix is installed?

[erikd]

Using mate-terminal as the emulator and :

> jq < dist-newstyle/cache/plan.json | grep vty | grep \"id\"
      "id": "vty-6.2-7fe99ecbb28a8328d7657fa9fdb0bfb415160015f22bdf4fea1be136db944837",
      "id": "vty-crossplatform-0.4.0.0-6ad0c13093c70c759a247514384c83aa14233cb624ab01d1dcea710541ea3eed",
      "id": "vty-unix-0.2.0.0-3dd206aaf8d8d3ed13d5a296247dfe3d827605119333a35963dd1db44ec1b15c",
      "id": "vty-unix-0.2.0.0-e-vty-unix-build-width-table-67138eeb5a8747a6d54a7e68001914dbb0df9331834b7087468bec1a26494900",

[kquick]

It gives us another set of datapoints.

I've tried a couple of my Brick apps in mate-terminal and don't see this issue.

If somehow the termcaps got written with some unusual alternative then it might cause unusual behavior.

@erikd, what linux distro and brick version?

[jtdaugherty]

@kquick for what it's worth: Vty's shutdown calls releaseDisplay and then releaseTerminal, and for XTerm-based terminals, those trigger the emission of the rmcup and cnorm capability strings (for releaseDisplay) and sgr0 and cnorm for releaseTerminal. So if any of those are off, that could explain this.

[erikd]

Wow it gets weird.

Do the demo programs that come with brick have the same behavior?

Yes, when run on the machine I was working on. On a second machine correctly restores the cursor, both with one of the demo programs and also with my program.

This looks like some issue with my machine.

what linux distro and brick version?

Debian Testing on both machines. I have run debums -s on the machine with the problems, but nothing was reported.

[jtdaugherty]

Is there perhaps something different about your shell configuration across those machines? Something present in your .bashrc (say) that might be contributing to this?

[erikd]

Same .bashrcs on both machines.

[erikd]

Thanks @jtdaugherty and @kquick . I think I will put this cursor issue down to something being astray on my particular machine,

[erikd]

My basic answer is #507 (reply in thread) .

Closing this.