A macOS Terminal mode

[willmcgugan]

macOS terminal doesn't render Textual apps well. It does a poor job of borders. I think we should consider a macOS terminal mode which override border choices to make it look better on macOS.

[viega]

Agreed on this; lots of people don't install more capable terminals.

[NfNitLoop]

+1 to this. My context:

I'm investigating Textual to use for a project. I'd like to propose using it. But if the out-of-the-box experience on Terminal.app is as it is today, it's not a great look for our product. Telling users to configure fonts and font spacing in Terminal.app, or install a different terminal to use our product is not something we want to take on. I'll probably be recommending a much simpler prompt-based UI instead of Textual as a result.

[willmcgugan]

@NfNitLoop What rendering issue in particular is a problem for you with Terminal.app?

[NfNitLoop]

Just the same sort of thing mentioned in the link from my comment.

ex:

In particular, border styles are a bit odd. I think the top/bottom borders are misaligned w.r.t. the background they're drawn in? It looks worse when there are multiple on screen.

---

As an example of what I'd expect, in python_toolkit, they show this:

Which in Terminal.app gets simplified to this (delta some themes, I think):

Their dialogs also use simpler rendering.

[willmcgugan]

Textual supports two border styles that allows for a different background color inside and outside of the border. These are the "tall" and "wide" border styles. Textual also supports a number of other border styles, including those used by prompt toolkit.

We are considering a macOS mode that replaces these styles with a classic style, but then that reduces the experience for those who are prepared to do the 10 second fix.

If you don't like how the "tall" and "wide" styles are rendered in Textual.app, the obvious solution would be to not use them. Run textual borders to see the other choices. It is trivial to replace the border styles for the builtin widgets.

[NfNitLoop]

It is trivial to replace the border styles for the builtin widgets.

How is that done? For every widget I use, I need to add a style to choose a different border type? Or can I do it in one setting?

We are considering a macOS mode that replaces these styles with a classic style

That would be my preference. I don't want to specify Button { border-style: dashed; } (or whatever the correct style is). Tall/wide styles do look good if they're rendered by a terminal properly. But I'd rather avoid them on broken terminals¹.

But if I/textual can determine that I'm running in Terminal.app (and, possibly: the user hasn't explicitly opted out), being able to say something like app.border_downgrade(["tall", "wide"], to="ascii") as an easy global fix-up would be handy.

Footnotes

1. Speaking of which… is there a way to open a bug against Terminal.app w.r.t. this rendering? It does seem to break the point of some of those characters. ↩

[TomJGooding]

Should Textual also consider a Windows Console Host mode? What about modes for embedded terminal emulators in IDEs such as PyCharm? And maybe modes for online services like Replit?

Personally I would rather Textual continues its impressive rollout of new features, rather than spending time trying to account for the deficiencies of certain terminal emulators.

[viega]

MacOS has a large user base of people who are comfortable in the terminal. I know MANY of them who use Terminal as their primary terminal. Even if we ask them to change, how many of them are going to want to do that? In my experience, most of them just won’t bother, and then I have to live with their impression of the UX, even if there is a solution in their hands. This is a case of “the customer is always right”: most of us are trying to remove friction from people’s lives, not add to it. The nicer it looks on the Mac, the more likely people like us are to go with it. And the more likely you are to impress OUR users who will then want to use it. Seems like a good investment of time to me. I couldn’t say the same things about adoption and importance for PyCharm. VSCode perhaps.

…

On Jun 20, 2023, at 5:51 PM, TomJGooding ***@***.***> wrote: Should Textual also consider a Windows Console Host mode? What about modes for embedded terminal emulators in IDEs such as PyCharm? And maybe modes for online services like Replit? Personally I would rather Textual continues its impressive rollout of new features, rather than spending time trying to account for the deficiencies of certain terminal emulators. — Reply to this email directly, view it on GitHub <#2658 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABELGQJSURMODGQFKT2GXSLXMILMPANCNFSM6AAAAAAYPIRP3Q>. You are receiving this because you commented.

[davep]

See also #3086.

[willmcgugan]

Not much we can do here, but it is documented now: https://textual.textualize.io/FAQ/#why-doesnt-textual-look-good-on-macos

[github-actions]

Don't forget to star the repository!

Follow @textualizeio for Textual updates.