Question: Does the asciimatics multiline text widget support a read-only scrolling log?

[pjfarleyiii]

Is your feature request related to a problem? Please describe. I have an application that needs a tui to support three refreshable but fixed-size text boxes for status information, one command input text box, and one large "log" text box occupying most of the terminal window where the messages describing the results of requested commands are appended to the contents of the log box for the entire time the application runs. The log box has to maintain all lines printed there in memory for re-display at any time.

Describe the solution you'd like I want the user to be able to tab to the log window and scroll up and down ALL of the messages printed in that box from the start of the application. The user should also be able to highlight and copy text via arrow and shift keys (or the mouse) and "copy" commands like Ctrl-C and then be able to use Ctrl-V to paste the copied text into the command window. Scrolling up and down the log messages should be possible at least with PGUP/PGDN/Ctrl-Home for beginning of log lines/Ctrl-End for end of log lines. A scroll-bar that the mouse can manipulate and mouse-wheel support for scrolling up and down the log window would be nice extras.

Describe alternatives you've considered I've looked at using ncurses/windows-curses, the "rich" project and the pysimplegui project. Pysimplegui comes closest so far, but I would really like a purely terminal-window solution rather than an actual GUI. The curses solution is not very portable, as I have found too many critical differences between the python ncurses and PDCurses implementations. It is also not friendly to simple escape-sequence text color control. "Rich" has a lot but no support for separate windows on a larger screen, it's all just one "window".

I do not actually need (or want) the user to be able to modify the messages printed in the log box, and in fact it would be very useful if the log box was "read only" and could not be modified.

Additional context It would be helpful if no "graphical" prerequisites needed to be installed when an application using asciimatics is installed, only whatever is needed to display and input text. This application is a purely text-based one, so requiring a user to also install graphical prerequisites seems like a bit much.

TIA for your help.

Peter

[peterbrittain]

That's quite a shopping list! But it's good function to have, so let me try to address all of it...

I think we already have most of that! What you're looking for is a readonly Textbox... This is available in the currently published version of asciimatics (by setting the readonly parameter on construction of the widget). It will allow you tab (or mouse click) to it and move around using the cursor keys.

If you want simple control code support (e.g. just to get colours), you can also add in the AnsiTerminalParser to the widget.

Clipboard support is left to the native terminal, so will typically be done through mouse selection of what you can see on the screen. It's possible to interface to the native clipboard in Python using other packages, but I'm afraid I haven't integrated it. Would be happy to help you figure out how to add that, though.

There is an old patch (see https://github.com/peterbrittain/asciimatics/issues/95) that allows you to run with fewer dependencies. I haven't merged it because it will break existing installations. Saving that for when I create a V2.0 package. The long and the short of it, though, is that you don't need Pillow if you're just going to use TUI widgets.

That leaves the scrollbars and mouse scroll buttons. I'm afraid there's nothing there yet. Adding a scrollbar is possible, but grungy. We could apply the same sort ofnpatch that I created for Listboxes to the Textbox. Mouse scroll buttons are messy in terminals... Would need to find out if they are sufficiently well supported now before saying more.

Hope that helps! Let me know what you think...

[pjfarleyiii]

Thank you for the prompt response, that is helpful. A few follow-up questions.

1. Can the text box retain the complete set of lines generated from program start so that (for instance) the user could scroll up to the very first line in the log and back down to the end of the log?

2. If the user has scrolled up the log list so that the latest line is not at the bottom of the window, does the next print to the log window automatically move the text down to display that new line at the bottom of the text box?

3. Aside from using the arrow keys, are there key bindings available or implementable for the PGUP/PGDN/Ctrl-Home/Ctrl-End keys to make scrolling by larger amounts possible, including up-to-beginning and down-to-end scrolling?

4. Can printed strings in any text box (not just a scrolling one) use ASCII escape codes to vary text color within a single printed line? E.G., if one desires to make one portion of text in the middle of a text line be red but the other text in the line be some other color, can one code the text as "Beginning of line" + RED-escape-code + "red text" + RESET-escape-code + "rest of text" ?

5. Do you support the "color index" ASCII escape codes (CSI38;5;nm and CSI48;5;nm)? What about the RGB change codes (CSI38;2;n;r;g;bm and CSI48;2;n;r;g;bm)?

Mouse wheel scrolling and / or a scroll bar would be nice but are not necessary for my application if PGUP/PGDN/etc. key bindings are available to provide for larger text scrolling movements. I do understand that mouse features are more difficult without an underlying terminal control environment like curses to provide mouse events to the program.

Regards,

Peter

[peterbrittain]

Taking those in turn...

1. Memory permitting, yes. I suspect that you'll want to drop old text at some point for perf reasons, though.
2. There is no print function in the Textbox. You would be updating the value to add more text. When you do this, the widget automatically sets the cursor to the end of the text.
3. Pgup/dn already exist. Ctrl codes are problematic in curses, so haven't been implemented. They need special mapping that won't necessarily work outside of xterm. Options to handle it are explained here: https://stackoverflow.com/a/31393336/4994021
4. You can use ansi codes in any widget that supports a parser. Or you can create your own custom widget too. See the terminal.py demo for an example. This has a lot in common with your use case, so is well worth a read.
5. Colour indeces are supported; rgb is not.

More mouse interactions are possible if the terminal supports them. Looks like xterm handles wheel mice (https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h3-Wheel-mice) but I don't know how good other terminal support is.

[pjfarleyiii]

Thank you again for a prompt response.

I expect that memory for the log text in this application will not be an issue since the total expected non-stop usage time is under an hour per single usage (and probably less in normal circumstances) and therefore the expected message output isn't anywhere near the gigabyte range, and probably only in the 10's of megabytes at worst. I will however plan on setting up log memory usage monitoring (perhaps with a high-usage alert function) in the log message code to verify my expectations.

Your explanation of how text boxes are actually updated is appreciated. I can deal with that.

Not having Ctrl or Meta key combination support is disappointing but not a show stopper. I can think of at least one workaround: giving the user instructions to press Home first and then PGUP as a second keystroke (with no intervening keystrokes) to get "go to beginning of log" behavior and similarly End and then PGDN for "go to end of log" behavior. Not totally intuitive, but workable. Maybe a popup for navigation instructions to help.

BTW, I do know from experience that both ncurses and PDCurses implementations do reasonably reliably support Ctrl-key and even some Meta-key combination inputs via the getkey() function. If all you use is the getch() function it is far more "interesting" to implement, especially for multi-platform support. BTDTGTTS.

I will certainly check out the terminal.py example as you suggest.

Lack of rgb color manipulation support is understandable (it's complicated and tricky, as I well know after trying to support it for curses), and not really necessary for my application. That was mostly a question out of curiosity rather than from any actual need. Index support for access to any available expanded terminal colors is excellent and mainly what I may need anyway.

As for mouse-wheel support, I can see from the link you provided that there are linux terminal issues but since I plan to provide a version for Windows as well as for linux, compatibility across the platforms is far more important than "nice to have" capabilities like mouse-wheel support for scrolling.

All in all, I think you have convinced me that it will be worth my time to give asciimatics a try. I will post other questions / issues as / if I encounter them.

Thank you again,

Peter

[peterbrittain]

Great! Feel free to use gitter for further questions. Am assuming I can close this now.