Window resize not handled (partially addressed)

[fried-sausage]

When i resize terminal window i get mess.

Does author consider this a bug?
One solution could be to do os.get_terminal_size() periodically.

[pfalcon]

This is similar to a bugreport in a downstream application: pfalcon/ScratchABit#13 . I consider this as a bug in a sense that I'm not going to close this report as non-bug, but don't have immediate plans to do anything about it, given that there're bigger bugs and an easy workaround exists ("don't resize").

[pfalcon]

Note also that your screenshot shows downsizing to a very small size (beyond the size of a dialog). And you get not not "a mess", but "line wrapping", as expected. What would you expect me to do in this case? Clip it? Nope, sorry. I'd expect being able to set a minimal size of a console required for a particular application. But consoles don't provide control codes for that. So instead, I expect users not to shoot themselves in the feet by setting too small a size. The minimum is 80x24, the hardcoded (and not queryable) size of the VT100 terminal (the baseline of any terminal emulation). None of picotui applications are expected to run with a smaller console (unless specifically designed for another size).

[fried-sausage]

your screenshot shows downsizing to a very small size (beyond the size of a dialog).

You can resize just a bit (within size of a dialog) with same result. Actually any resize i make breaks it.

not going to close this report as non-bug

Ok, i`ll try to find workaround to handle resize beyond 80x24 if i have time.

[peterjschroeder]

Automatic resizing would be a great addition. This is a pretty common feature in TUIs/GUIs. Right now in my code, I am dividing all widgets coordinates by the screen width/height. This works most of the time.
The problem is with this method, is you end up with floats which have to be rounded. On some screens this causes the widgets to be slightly off.
I'm thinking if by default picotui always assumes an 80x20 screen, than picotui can get the screen width/height and evenly divide the extra space to each widget. I'm still not sure what to do with the remainder spaces tho if the amount of widgets do not divide equally into the screen dimensions.
I did notice that the Dialog widget expands on its own depending on the length of its context.

[pfalcon]

You can resize just a bit (within size of a dialog) with same result. Actually any resize i make breaks it.

I can't reproduce this. Ubuntu 16.04/Mate Terminal 1.12.1. I can't resize down without any problems while no wrapping occurs. When it starts to wrap, yes, it starts to wrap. The screenshot shows moment of the first wrapping - "w" in "Yellow". Wrapping occurs not on resizing, but on tabbing thru widgets after it (i.e. when radiobox gets redrawn to show that it's focused).

[pfalcon]

The overall situation is that terminal resizing cannot be handled in the general case. Specifically, due to braindeadness of Xterm designers, they didn't provide a way to communicate resizing event via escape sequences to the terminal. This mean resizing detection can't happen over plain serial line. API-wise, the only way to detect resizing on a POSIX system appears to be to handling SIGWINCH OS signal. Higher-level terminal transport protocols (telnet, ssh) workaround Xterm braindeadness by communicating resize events using their own adhoc means. But the only way they can deliver that event to an application running in a terminal is again by sending SIGWINCH. Which limits it to POSIX system, e.g. wouldn't work on Windows (well, on Windows, its own adhoc way to communicate a resize event can be used, yeah, then there's a problem for we-based terminal emulators, etc., etc.)

Prooflinks:

• https://wiki.archlinux.org/index.php/working_with_the_serial_console#Resizing_a_terminal
• https://cafbit.com/post/terminal_window_size_detection_over/
• https://www.ietf.org/rfc/rfc1073.txt
• https://unix.stackexchange.com/questions/16578/resizable-serial-console-window
• http://shallowsky.com/blog/hardware/serial-24-line-terminals.html
• http://lua-users.org/lists/lua-l/2005-09/msg00591.html

[pfalcon]

Approaching it from picotui's side, picotui follows KISS approach whenever possible, and for example, calculates and stores absolute screen coordinates for each widget (and subwidget, e.g. a part of a dialog). So, currently it's not possible to, for example, to move dialog dialog by updating its coordinates - its widgets will stay at their original coordinates.

That of course can be "fixed", but adds extra overhead and complexity. Given all the complications with resize handling described above, I don't think it's worth to do that.

This leads to the following proposal: I'm ok to add support for optional handling of resize events, but all the burden of handling that falls on app's shoulders, picotui isn't going to change its internal implementation to support something which can't work in the general case anyway.

Specific things wise, this means that an app will need to re-layout (and that means re-create) all its dialogs etc. (vs just updating dialog coordinates). Again, this is the only general way to deal with it. Consider for example that if you really want to handle different screen widths, then your dialog should be able to adapt e.g. between one-column and two-column rendering of options.

(This is all being written from the experience of writing an app which will show a dialog always centered on a screen. An easy way to do that would be to update dialog's coordinates, but nope, what one needs to do is to recreate dialog with new coordinates instead.)

[pfalcon]

In e958af4, set_screen_resize() function is added, similar to existing set_screen_redraw(). Even though, it's tentative and subject to change.

[pfalcon]

In d083cfe, a sample is added. (If resizing window with real-time content updates (as usually the case with current window managers), it sooner or later gets hit by #23.)

Keeping this issue open for now, until this feature is tested and

[peterjschroeder]

Tested and it works.

If #13 can be worked out, the choices can be easily looped through and stored before recreating and than set back to their original settings.

[pfalcon]

@peterjschroeder : I'm not sure "Dividing coordinates" matter belongs to this issue, titled "Window resize not handled". So, if you're interested in the former, I'd suggest to open a separate issue.

[peterjschroeder]

Sorry, I figured this was the right place for it because it is window resizing. Just the initial resize, not after application launch. I'll open a separate issue.