technical reasons behind disturbed operation on a standard terminal?

[nnako]

Hi,

a couple of weeks ago, I ran into textual, checked it, and was surprised that the provided demo seems to really work on a standard (built-in) Windows terminal. This fueled my fantasy to finally be able to provide Python applications (built with pyinstaller) which use appealing graphical user interfaces while being cross-platform and avoid "real" graphics as provided e.g. by tkinter, GTK, WxPython or QT.

I thought, every application relying on textual would be able to benefit from the stable features and provide their service even on the vanilla Windows terminal. But this does not seem to be the case:

The drawing shows that all the icons have been messed up. And not only their appearance on the screen but also the actions connected to them don't seem to behave as expected / intended. Even though the readme text mentions the conflict with the vanilla Windows terminal, I was wondering why this would necessarily have to be the case.

So, are there any technical issues / restrictions why textual-paint currently doesn't manage to provide the ability to be used on vanilla Windows terminals?

Thanks.

[1j01]

There are a few related issues:

• Font support: it's up to the terminal to provide the font. Unlike desktop or web applications, a TUI can't specify a font to use. In the screenshot you provided, I can see that the font is missing coverage for most of the characters used for icons. They are shown as placeholders instead (� and so-called tofu).
• Character measurement: some characters, including many emoji, are two cells wide, and there's no easy way to measure the width of characters. The Textual framework uses a lookup table of widths for different characters, but it's not consistent between fonts/environments, so it's not perfect.
  • The terminal is designed to be written to left-to-write (generally), with characters being placed implicitly based on what has been output so far. When characters are measured wrong, this creates a ragged edge for everything to the right, distorting the canvas.

However, Textual Paint does provide an option that lets you run it on the vanilla Windows console, you just have to give up the Unicode icons:

textual-paint --ascii-only-icons

Or if needed, the whole interface can be reduced to ASCII:

textual-paint --ascii-only

That said, the conhost.exe on Windows 11 does support some Unicode these days. This is what it looks like for me, by default:

It's funny, the whole "Yes" button was duplicated! This is why you should always read both buttons before clicking, I suppose, haha.

Also it's interesting that on my system, the borders are rendered as boxed question marks, whereas on your system they seem to be rendered okay (albeit with seams).

Here's what it looks like with --ascii-only:

For reference, here's what Textual Paint looks like running in the modern Windows Terminal app: