Menu ? completely changed

I updated my git repository today with the latest changes. The menu ? It’s not what It’s not what it used to be, did I miss something?

Yes, I redid the menu last week. The two column menu was hard to maintain and it didn’t get updated regularly.

I’m going to use the same help system to handle all the -h command helps as well so it is consistent across the firmware.

You might also notice an improved W command :slight_smile:

The new menu makes it a little inconvenient to see the top lines if they scroll up too far. If you use screen(1), you can type
“Control-A ESCAPE” and then scroll up. You can even copy text.

I haven’t figured how to do this using tio(1). I have to use the mouse on the scrollbar. Any tips?

Would it be helpful to paginate it? I also think it’s too long.

Ah. I figured out how to do it with tio(1). Shift-PgUp/PgDn scrolls the screen up. This is built into GNOME terminal.

Pagination on the help could be useful, but each screen can be a different length. And ideally you would want that, or else make each help screen less that 24(?) lines long. And that would be a pain to maintain, and use if you have a big screen.

Unix systems have the “| more” or “| less” mechanism for long screens. But the app reads the TERM environment variable to get the “li” value to determine the number of lines to display. I don’t know how the BP can do that.

Good points. We do attempt to grab the VT100 rows and cols, so we could adjust. I don’t know how reliable the result is. I should make it print the result in the info screen for debugging.

It’s a hard problem. There are times the toolbar on the bottom gets screwed up. I haven’t had time to create a repeatable scenario, so I haven’t reported it. I usually disable the toolbar when it happens. Having a display mode that simply clears the screen would be nice.

I saw you mention that in another thread. Is it a consistent problem? I did have similar issues and squashed them 2ish years ago for my terminal. I would like to figure out what is going wrong in your terminal. I assume we’ll find out why Ncurses exists :lobster:

It occurs often. I’ll try to recreate it for you.

When I use minicom or Putty the bar gets messed up when I resize the window.
Tio also has the same problem, you have to remember to maximize the shell window and then invoke Tio

It’s on my list to add a windows redraw command. Maybe also periodically query the window size and redraw? I’ll see what I can do today

Ok, I did a quick hack to see if I could detect the terminal size change. It seems I can.

Do we check periodically the terminal size and then redraw the toolbar if it changed?

I actually send the 80 columns command on startup already, should that be sent again if the user changed the width?

What is the behaviour of your terminal when you resize? On Teraterm the screen is cleared and the cursor starts at the top again.

If I redraw the toolbar should I send like 4 new lines to make room for the toolbar so it preserves whatever you have on screen, as opposed to doing a complete re-initilization which would clear the screen? For me this wouldn’t matter, but if your terminal keeps data after a change in size, I wouldn’t want you to lose anything important.

1 Like

now that you have found a way to know when and how much the terminal window changes following a resizing, I would propose something a little more difficult but which would also fix the menu? double column.
When resizing you save the column value in a global variable.

The management of the entire window could be done with a sort of screenBuffer which is populated and displayed upon a “reload” and takes into account any resizing.

The menu ? it could be managed with a multidimensional buffer that is populated starting from the individual buffers during the startup phase (it doesn’t change anymore anyway). The order of the indexes must be maintained, but this should not be difficult to do.
Did I write silly things?