I'm probably a bit more positive to TUI type applications than you (and don't care about theme matching, docks, or notifications), given e.g. my editor runs purely in a terminal (and I'm writing a new terminal...) but I think we sort-of agree when you say it's just a thinly disguised GUI.
While I think it's impressive how good they've made it look, for me the point of a TUI is for it to be simple and pared down. It's nice if it looks good, but I want something keyboard driven and command focused rather than UI element focused. I'm not sure who the target group is here. Are there enough people who love to work in a terminal but still want their apps to look like GUI apps?
EDIT: From elsewhere on the site, it seems like they're trying to target people who would like to write GUIs, but find writing GUIs too hard, and that the TUI part is just a starting point. I'm ambivalent of the chances for that to succeed, but who knows.
I think you are spot on classifying the project as “for people who want to write GUI”, based on the GitHub read me (which has screenshots) it does not appear to be a tui on the web at all
https://github.com/Textualize/textual-web
It looks like on the web it is rendering widgets that the library can also render via tui on the terminal. So it seems the title is quite misleading. The web based ones are not using font glyphs to build up a ui.
ack, I was fooled by the screenshots. That is even less advisable than I had feared. the widgets would likely have very poor accessibility if they are implemented as text on canvas.
> I want something keyboard driven and command focused rather than UI element focused.
I think we are in more agreement than you might suspect. Command-driven operation is how I tell a good UI from a poor UI. Good interfaces are intuitive for beginners and provide a smooth learning curve to mastery. Good way to get there is for the interface to remain simple and consistent on the surface, but unravel more specialized power as you dig in, and ultimately allow full customization.
It's all the things that make macOS UI so good IMHO: apps look and work similarly at the surface, have consistent keyboard shortcuts, you get excellent feature discoverability through the top bar menu + search box, and you can even rebind any menu item to a custom shortcut (both per-app and system-wide) through the stock Settings app. Pitch that against your typical selection of TUI apps: vi, less, top, screen, tmux, irssi, mutt, etc all do things differently, the *only* thing they have in common is a grid of character cells.
Terminal emulators themselves unfortunately seem to be the anti-thesis of good UI. The ecosystem is highly fragmented. Writing a TUI app from scratch (yes I wrote my own TUI text editor) is hell, if you want to aim at more than the lowest common denominator, while ensuring portability (I'm talking just Linux+BSD+Mac; I wouldn't even know where to start with Windows). Even if you chose not to waste your life and started with Termbox or heck even ncurses, you'll still be fighting a dragon at the end of every dungeon level: keybindings (why can't I do ctrl+shift+a!?), colors (crap it ended up being black on black!), etc.
> From elsewhere on the site, it seems like they're trying to target people who would like to write GUIs, but find writing GUIs too hard, and that the TUI part is just a starting point.
I haven't looked at the framework yet (TL;DR...), but that seems like a goal that I could get behind. Writing a good GUI app nowadays means you have to learn and use platform-specific APIs, and cross-compiling is a massive pain.
Beeware (https://beeware.org/) is working on something pretty good in that direction. I encourage everyone to have a good look at it.
Mac OS doesn't have access keys for the menu bar. Either someone assigns a keyboard shortcut, which you can use, or you have to use the key combo that focuses the menu bar and then arrow through the menus. The first time I got a Mac, I thought this was insane. When I sold my MacBook years later, I still thought it was insane, because it is.
In contrast, the IBM Common User Access guidelines established that you can press Alt plus another key indicated by an underlined letter associated with a given menu option in order to open/select that option, with subsequent letter keypresses opening other menus further still or selecting menu items. Windows still supports this and both Gnome and KDE(?) apps that still use traditional menu bars do, too. (Gtk used to even let you assign which letters opened which menus/items directly from the main application UI—no opening up any control panel—but they got rid of it around Gnome 3, as I understand it.)
> Mac OS doesn't have access keys for the menu bar. Either someone assigns a keyboard shortcut, which you can use, or you have to use the key combo that focuses the menu bar and then arrow through the menus.
Try Cmd+Shift+/ (aka Cmd+?) and typing a few letters of the command you want to invoke. It's pretty much the same mechanism that Emacs uses (C-x followed by the command name).
I'll admit it's not very discoverable.
> In contrast, the IBM Common User Access guidelines established that you can press Alt plus another key indicated by an underlined letter associated with a given menu option in order to open/select that option
First, Macs don't have an "Alt" key ;) But more importantly, CUA dates back to 1987, which is predated by the original 1984 Macintosh - which by that time already had established quite a few conventions of its own. I wouldn't blame it on Apple that they've stuck with their own conventions, their OS is arguably the most consistent one on the market thanks to that. Some people (hi) greatly value that consistency.
I think it could be argued either way about which convention is better, I'd say it boils down to preference.
O[1] RLY?[2][3] (Whether they have one or not is beside the point.)
> more importantly, CUA dates back to 1987, which is predated by the original 1984 Macintosh - which by that time already had established quite a few conventions of its own. I wouldn't blame it on Apple that they've stuck with their own conventions
Irrelevant. The Mac OS isn't the same as the one that shipped in 1984. It certainly didn't have Spotlight then, for example. Supporting CUA-style menu access keys would be an additive change—the same way that importing the benefits of the UNIX userspace by way of NeXTStep was additive (but far less invasive than that one); no one said to stop supporting other menu access methods.
> Supporting CUA-style menu access keys would be an additive change [...].
As I said, Macs don't have an Alt key; there's an Opt key, which (depending on context) can work like AltGr or Alt (the latter usually when combined with Cmd). You can't draw a 1:1 comparison with a PC keyboard, because they're just different things.
Overloading Opt to access menus is not an additive change. Opt-e in my keyboard layout produces "ę"; Opt-x produces "ź". You'd take away my ability to type in my native language.
Introducing new modifier keys (say OptGr+e would produce "ę" but Opt-e would access the menu) would be a drastic and unwelcome change. I would equate it with changing the meaning of "Shift" when pressing number keys. It's something you just don't do to your users, no matter how much more sensible it appears to you.
Again, it's all platform conventions. When you travel to Italy, you don't bitch that nobody speaks German - even if German is standardized, and officially spoken in three different countries.
While I think it's impressive how good they've made it look, for me the point of a TUI is for it to be simple and pared down. It's nice if it looks good, but I want something keyboard driven and command focused rather than UI element focused. I'm not sure who the target group is here. Are there enough people who love to work in a terminal but still want their apps to look like GUI apps?
EDIT: From elsewhere on the site, it seems like they're trying to target people who would like to write GUIs, but find writing GUIs too hard, and that the TUI part is just a starting point. I'm ambivalent of the chances for that to succeed, but who knows.