Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Writing Programs with Ncurses

invisible-island.net

Post reply on HN
Print view View original

81–90 of 93 posts

Re: Writing Programs with Ncurses

#81

Post by tspivey »

caf wrote: post #79
tspivey wrote: post #57

Earlier quoted context omitted.

You don't need to dump the screen, the screen reader takes care of letting you explore the screen by line, word, character, etc. Some curses programs work reasonably well with screen readers (e.g. Mutt and WeeChat). One useful way to make them more accessible is to put the hardware cursor somewhere useful, even if hidden. Mutt puts it on the same line as the currently-selected message, and if braille_friendly is set,…

Can you give any more guidance on what might constitute "somewhere useful"? Is the hardware cursor position the default place to start reading from?

Somewhere useful depends on the app. In an editor, it's the line of text I'm editing. In a file manager, it's the currently focused file.

The hardware cursor is where it will start reading when I press read current line, word, etc.

Re: Writing Programs with Ncurses

#82

Post by badsectoracula »

KronisLV wrote: post #53
rbanffy wrote: post #46

Earlier quoted context omitted.

> Developing a GUI feels awfully complicated It’s kind of a language thing. When Visual Basic came out, it’s UI builder was ahead of anything I’ve ever seen on a GUI and more versatile than HyperCard (and much faster). A decent GUI builder attached to an IDE and some nice language support goes a long way. That’s the opposite of the experience you get when using, say, Flutter or React Native. The language is better th…

Sadly it seems a thing of the times, perhaps due to the direction the industry has gone in. I recall creating GUIs in Lazarus/FreePascal was really easy and an enjoyable experience, however there are so few libraries and integrations for it, that it's a non starter for new projects. There is Swing for Java which had a really nice GUI builder in NetBeans, but the other IDEs are somewhat lacking in comparison and then…

> I recall creating GUIs in Lazarus/FreePascal was really easy and an enjoyable experience, however there are so few libraries and integrations for it, that it's a non starter for new projects.

Lazarus and Free Pascal are used for new projects all the time, if anything judging from the mailing lists, they are more popular than they've ever been (hell, unlike only just 5-6 years ago, i rarely see people mention that they remember using Turbo Pascal back in their school years whenever a new release is made nowadays :-P).

Free Pascal comes with a ton of bindings out of the box, but making new ones for C should be simple with the included h2pas tool (i think there is also a frontend for Lazarus though i never used it myself). There should also be already made bindings for stuff that aren't distributed with Free Pascal. You should also be able to use Rust libraries by going via cbindgen -> h2pas, as well as any other language that can "export" C header files for FFI. Beyond that you can do it manually, which can be a pain, but that is the case with pretty much any language.

Of course using libraries from scripting languages and managed languages like Python, JavaScript, Java and C# is harder but not impossible (and not really that much harder than using them from any other native language, C included).

Re: Writing Programs with Ncurses

#83

Post by ggerganov »

einpoklum wrote: post #71
ggerganov wrote: post #18

Earlier quoted context omitted.

For C++, there is also ImTui that I wrote sometime ago: https://github.com/ggerganov/imtui I made a few sample apps with it, such as HN client and a WTF configuration tool. They are both linked in the repo if you are interested. I still want to make some other cool terminal app with it, but haven't found a nice idea yet.

So, does that actually work in a proper terminal? Or is it only when you have a framebuffer available?

> does that actually work in a proper terminal?

Yes - all of the examples in the linked repo run in the terminal and are also ported to the Web using Emscripten.

> Or is it only when you have a framebuffer available?

ImTui creates a framebuffer and renders the scene using ASCII characters into the framebuffer. To create the scene, you can use the entire API of Dear ImGui [0] - it has various options for creating windows, buttons, sliders, tables, checkboxes, colors, etc.

You now need to display this framebuffer somehow and also provide input from the keyboard and the mouse. ImTui provides an ncurses interface for this. It uses the ncurses API to render the characters in the terminal and also to grab input from the keyboard and the mouse.

Technically, ncurses is an overkill for this application, since ImTui only uses only a very small subset of the ncurses functions. But this was the easiest way to make it work.

ImTui can be extended with more interfaces. For example, I made a second one which I call "Emscripten" interface. It's purpose is to provide an API to easily export the framebuffer to the JS layer and to easily grab input back from the JS layer. This way, I can have a single application code that builds and runs both in the terminal and on the web.

[0] https://github.com/ocornut/imgui

Re: Writing Programs with Ncurses

#84

Post by badsectoracula »

habibur wrote: post #30
mrighele wrote: post #17

Earlier quoted context omitted.

I don't think it is exactly TUI vs GUI, but more keyboard-first vs mouse-first, i.e. how you interact with it. Granted, Desktop GUI are usually developed mouse-first, but it doesn't have to be that way: if you take windows 98 / windows 2000, you could get everything done more efficiently with a keyboard than with a mouse. Just think about the difference between an app developed specifically for the desktop (mouse) or…

Right. Plus responsiveness. Terminal apps have faster response time than GUIs. And when someone is typing like 10 chars per seconds it matters. The usecase is different between terminal vs GUI. Where in GUI you look - choose - decide and click. And in terminal you blindly storm on the keyboard as fast as you can.

Terminal apps are running under a GUI terminal for at least two decades now, there isn't really a reason for a GUI application to not be as responsive as a terminal application, it is just that "modern" GUI toolkits being slow.

IMO a reason is because nobody seems to bat an eye when faced with a "TUI" made out of lines, boxes and garish colors but if a GUI is made like that it is suddenly ugly so toolkit developers put a ton of effort into shiny looks.

But try a GUI made with Win32, Motif, Tk (not Ttk) or even Gtk1 and it'll be as responsive as any terminal application (of course it also depends on the application, there isn't much the GUI can do if the application abuses it or is sluggish for other reasons ).

Re: Writing Programs with Ncurses

#85

Post by badsectoracula »

veddox wrote: post #72
codedokode wrote: post #37

I don't like text UIs. They try to emulate GUI but do it poorly. You should either make a classic console program, that can be scripted, piped, etc., or a real GUI.

> They try to emulate GUI but do it poorly I dispute that point. Firstly, because TUIs and GUIs were developed pretty much in parallel, as far as I‘m aware. But secondly (and more importantly), because TUIs fill a different niche and follow a different philosophy to GUIs. TUIs are primarily intended for environments where GUIs are either not available (e.g. SSH), unnecessary (e.g. servers), or overkill (e.g. very old…

> TUIs are primarily intended for environments where GUIs are either not [...] or overkill (e.g. very old computers).

You'd have to be using a very old computer considering Windows 3.0 worked even on an original IBM PC. Though granted, you needed at least a 386 for it to be usable.

Chances are your GUI toolkit is too bloated, but that is the fault of the toolkit you chose, not GUIs themselves - use a more lightweight toolkit.

> In terms of design and UX philosophy, they are much more concentrated on keybased rather than mousebased interaction

This is up to the application, there is nothing that forbids GUIs to be fully keyboard controlled (in addition to mouse of course).

> and bring their own set of conventions that are markedly different from GUI design philosophy.

Pretty much every TUI either has its own set of conventions or mimics established GUIs or a mix of both, so not really.

Re: Writing Programs with Ncurses

#86

Post by randomswede »

gonzus wrote: post #11

I have looked into this in the past, and have always felt discouraged by the lack of good support for modern keyboards and mice. With ncurses and similar, you can only detect (a subset of) keys modified by Ctrl and Alt; I would like a portable way of finding about multiple combinations of modifiers, with any key in the keyboard, including function keys, home, end, up, down, etc. Ideally, I would also like to detect m…

I think part of it is that what good is your TUI if it doesn't work with, you know, a terminal, hooked up on a serial port? Where you will be unable to have anything but "shifted" and "control" characters easily recognisable. Some terminals did have a "meta"-equivalent key that simply forced the highest bit on, making them INSTANTLY incompatible with anything but US ASCII.

Sure, you can write a TUI library that allows you to interact with "idealised terminal of choice", but I'd prefer one that works with one of the serial terminals I actually have, somewhere, around the place.

Re: Writing Programs with Ncurses

#87

Post by rbanffy »

nix23 wrote: post #67
rbanffy wrote: post #65

Earlier quoted context omitted.

> Hey! I have my beloved HHKB Professional 2 since years :-) Doesn’t come even close. ;-)

Don't you dare to say anything more!!! But i believe you ;)

You don't need to trust me. Trust the almost physiological reaction they provoke on an unprepared human: https://www.youtube.com/watch?v=hNRH1ULmbNA

Re: Writing Programs with Ncurses

#88

Post by rbanffy »

badsectoracula wrote: post #82
KronisLV wrote: post #53

Earlier quoted context omitted.

Sadly it seems a thing of the times, perhaps due to the direction the industry has gone in. I recall creating GUIs in Lazarus/FreePascal was really easy and an enjoyable experience, however there are so few libraries and integrations for it, that it's a non starter for new projects. There is Swing for Java which had a really nice GUI builder in NetBeans, but the other IDEs are somewhat lacking in comparison and then…

> I recall creating GUIs in Lazarus/FreePascal was really easy and an enjoyable experience, however there are so few libraries and integrations for it, that it's a non starter for new projects. Lazarus and Free Pascal are used for new projects all the time, if anything judging from the mailing lists, they are more popular than they've ever been (hell, unlike only just 5-6 years ago, i rarely see people mention that t…

It wouldn't be too difficult to build on Glade or QtDesigner and better integrate it with code generation. Both Glade and QtDesigner output language-neutral UI descriptions that could be used to build any sort of app.

Re: Writing Programs with Ncurses

#90

Post by badsectoracula »

rbanffy wrote: post #88
badsectoracula wrote: post #82

Earlier quoted context omitted.

> I recall creating GUIs in Lazarus/FreePascal was really easy and an enjoyable experience, however there are so few libraries and integrations for it, that it's a non starter for new projects. Lazarus and Free Pascal are used for new projects all the time, if anything judging from the mailing lists, they are more popular than they've ever been (hell, unlike only just 5-6 years ago, i rarely see people mention that t…

It wouldn't be too difficult to build on Glade or QtDesigner and better integrate it with code generation. Both Glade and QtDesigner output language-neutral UI descriptions that could be used to build any sort of app.

Lazarus already saves the forms into text-based files that you can read, however this is really missing the point and reducing an advanced RAD tool to nothing more than 80s-circa resource editor for Windows. There are tons of tools like that.

The big feature of Lazarus (and Delphi and C++ Builder, etc) is how integrated the entire thing is - not just the form designer but also the framework being itself designed around its use inside Lazarus' form designer, object inspector, etc and the language having features (e.g. published properties) explicitly for such use and the IDE knows about the framework so it can automatically plug things, generate code (not in the Glade style of unidirectional generation but in that the IDE understands the code and can modify it). Hell, even C++ Builder actually feels a bit "alien" to VCL (which was originally made for Delphi and Borland had to add several extensions to C++ for it to work, which only really worked because they had their own compiler, linker, etc to work with).

The closest you could get to that elsewhere is QtCreator but you quickly realize (assuming you were used to Lazarus-like tools, most developers actually do not realize that) you are working with something that was meant to be coded against instead of used with visual designers (which is kinda backwards IMO considering the "G" in GUIs and kinda remind me a quip about Motif back in the day about how its documentation was a bunch of volumes almost without any screenshot :-P).

But if you want to do it right, you can't really work around the need for all these to be integrated with a unifying vision. Even Lazarus and Free Pascal, which are technically different projects, largely managed it because they basically did what Delphi already had done - and most of the warts when using Lazarus come from not being a truly integrated project like Delphi was, like issues with different FPC versions or relying on GDB as a debugger (which is the #1 source of debugging issues, fortunately there is a new debugger in works which can work as part of the IDE itself and personally find it to work fine, though it isn't enabled by default).

Post reply on HN