281–290 of 299 posts
Earlier quoted context omitted.
If one were to start a project from scratch today, with the goal of having such a hyper-efficient TUI, similar to the Lowes/Costco ones, to be accessible via SSH/Telnet/locally... are there frameworks out there to use? Would my best bet still be ncurses? Are there simpler alternatives?
charm.sh is probably what you're looking for
Earlier quoted context omitted.
But there are no benefits, you can replicate everything in terms of user interaction identically in a more readable/better looking GUI app, so efficiency is maintained
Sure you can , but it's rare to see a GUI app built keyboard first and specifically optimized for the productivity of power users. The list of apps that do this successfully is a tiny fraction of the total. - Excel - 3D modeling tools - Adobe Creative apps - Programming IDEs - ? Also, if you are focused on that metric: the productivity of the power user, then in many cases adopting a more modern GUI framework will no…
Thus there is no innate framework benefit, only downside, so it doesn't make sense to handicap yourself tying to this legacy
PC-FAND is now on github... I think you should be good with Google Translate https://github.com/alisoss/pcfand
From the pre-GUI era, one favorite would be Ken Thompson's text editor "ed". It's built with a print output in mind and it doesn't show you the text itself by default. You'd have to target a line range and specify an action such as replacement or even to print it out to screen or paper; using the now famous g/re/p pattern. The minimalism is really cool. ed is still around as a vital part of the vim text editor to thi…
That's not what is commonly meant by "TUI". But as you mentioned, these old UNIX tools were really meant to be used with output printed to paper, which formed part of their "user interface": With CRT terminals, they actually become less usable, since anything that scrolls off the screen gets lost (even today in a terminal window, there is usually a limit to how far you can scroll back). And I feel like all those UNIX…
This is how I feel about emacs. Sure it contains the world, but you have to memorize the map to get anywhere interesting. I do like emacs and I do use it daily, but my command repertoire is under a dozen in number.
In stark contrast to most GNU/*nix tools, I really liked MS-DOS's edit.com text editor. Unlike emacs or vim or even nano, it didn't have a bunch of invisible shortcut keys, just a Windows-like drop-down menu system (but rendered in DOS). You could easily browse through the menu hierarchy, but still memorize certain shortcuts that you often use (just like Windows). In later versions you could even use the mouse to sel…
To me, Borland Turbo Pascal / Turbo C are the apex of IDEs.
there have been lots and lots of advancements in IDEs since then, are none of those advancements useful to you? not everyone needs or wants a lot of those things, i'm sure, but they have utility which the Turbo* console IDEs lacked.
Where I live we have a big science museum[1]. Besides a real Cray you can sit on, it had some public experiments with TUIs done in Borland's TurboVision. I loved that as a kid in the late 80s and early 90s. For me it was how the future looked back then. Over the decades I went to the museum often and the future turned into the past. It's only recently when the museum got a new director and a huge renovation when the…
Yes! It's very surprising how small it was. Images back in the day gave the impression of a hulking monolith.
Earlier quoted context omitted.
To me, Borland Turbo Pascal / Turbo C are the apex of IDEs.
really? the apex? that's an interesting perspective, to me. there have been lots and lots of advancements in IDEs since then, are none of those advancements useful to you? not everyone needs or wants a lot of those things, i'm sure, but they have utility which the Turbo* console IDEs lacked.
Earlier quoted context omitted.
> Legacy apps never die I think it's a mistake to frame this as legacy vs. new. There are real benefits to the approach taken by these TUI applications and it would behoove modern app designers to learn from them. It's perhaps the case that those coffee shops will someday adopt a TUI once they reach a level of sophistication. As an example: I believe Starbucks uses a TUI for order processing.
But there are no benefits, you can replicate everything in terms of user interaction identically in a more readable/better looking GUI app, so efficiency is maintained
And that can be a nice improvement to e. g show your code at a normal size but pop a tooltip up with smaller text, or have the linter/errors tab be a smaller font.
But that's a difference and not necessarily an improvement, because having a consistent font and fixed width text can make things more predictable and faster to interact with as you don't have to scan around as much.
PyPI: https://pypi.org/project/logmerger/ Github: https://github.com/ptmcg/logmerger (screenshots in README)