/tech/ - Technology★

>Also, ranger somehow uses images, how can images be seamlessly used. Can other types of things be items, like videos, and music (of course some other external program would be called to properly play it) What about resizing?

ranger uses images with an X11 hack, you can't use that with ncurses. I don't know if you can play music or video with it.

>Wouldn't it be great to have a library on top of ncurses which allowed you to do these things plus more easily

There are libraries built on top of ncurses to make stuff easier, but I don't have any experience with them. Just google it and you should find them.

Use QT like a normal person.

There is literally no good reason for making anything with Ncurses, it's slow, inefficient and convoluted.

>>1038476

must be some framebuffer thing. even ttys arent like they used to be

fun fact, you can easily write stuff to /dev/fbcon. It's a device. With ffmpeg and the right format, you can "write" pictures to it. Ranger probably does something like that.

With terminal emulators in X11 you can use sixels, but only if the terminal emulator in question supports it. There is also yaft, which is a framebuffer terminal (doesn't need X) it also supports sixels (and 256 colors)

>>1038367 (OP)

>I am a minimalist

You have the mental illness part down but I think everything else is wrong. You sound more like a ricer or LARPer.

I'm sure someone has already made a XUL type markup for ncurses.

>>1038476

Unrelated question: How do you install the the English version man page for w3m? When I try it I only get the German version.

Is Ncurses really worth it when you have access to a real GUI? It seems like it's just as complex as traditional GUIs, just with worse capabilities and random limitations due to being console based. For basic modal dialogues and shit it's okay, but I see people trying to draw graphics with ASCII art and it just looks fucking retarded.

The problem with GUI libraries is they always want to be an enterprise-ready library that lets you customize and modularize every single thing about your GUI so that you can actually make real, professional programs with it like Office or whatever the fuck. But 90% of the time you're working on a small project and you're not gonna use use 90% of those features, and they create complexity up front because now basic things are more complicated than they need to be. I wish there was a library that is deliberately limited in how powerful or customizable it is, as a trade off to allow minimal effort GUI for prototyping/hobby projects. If I ever make the app mature enough to sell, I'd just hire a real GUI programmer.

>>1038436

Well, if it's something that can only run in a terminal, like an OS installer, driver manager (in case graphics crash) or something meant for ssh.

>>1038510

I know it's not minimalist in the sense of the complexity that such a library would bring.

Also, I regret saying that, I'm not a minimialist, but I try to be.

For example, I try to not use desktop enviorments but just window managers and I don't even have a GUI file manager.

most of my tasks can be done using the command line, except web browsing of course

>>1038570

but the command line looks cooler

>>1038367 (OP)

>ranger somehow uses images

`w3m` does image display, not ranger.

And that also isn't perfect. I had massive problems with image in the terminal, and ranger straight up didn't show any images. Instead i use `img2txt` for previews, for that maximum autismo.

As for a more robust, fuller implementation of graphics in the terminal: i had some luck with trying libsixel( https://github.com/saitoha/libsixel ), and it worked, kinda. Displaying a lot of images is absurdly slow and requires massive computing resources. I mean the M$ Losedows definition of "a lot": 40 images is when my problems started>>1038367

>>1038590

Dwarf fortress looks like ass tho.

>>1038367 (OP)

>minimal

Ncurses is anything but minimal. Not only is it extremely bloated, any program that uses it will have memory leaks because Ncurses has an intentional memory leak. That's peek UNIX weenie design.

>>1038482

No, you literally just use the X11 API to just set the pixel values for that window. As long as the window doesn't redraw over it, your image will be their.

>>1038601

>Ncurses has an intentional memory leak.

lol wut

>>1038603

>Perhaps you used a tool such as dmalloc or valgrind to check for memory leaks. It will normally report a lot of memory still in use. That is normal.

>The ncurses configure script has an option, --disable-leaks, which you can use to continue the analysis. It tells ncurses to free memory if possible. However, most of the in-use memory is "permanent".

>Any implementation of curses must not free the memory associated with a screen, since (even after calling endwin()), it must be available for use in the next call to refresh(). There are also chunks of memory held for performance reasons. That makes it hard to analyze curses applications for memory leaks. To work around this, build a debugging version of the ncurses library which frees those chunks which it can, and provides the _nc_free_and_exit() function to free the remainder on exit. The ncurses utility and test programs use this feature, e.g., via the ExitProgram() macro.

https://invisible-island.net/ncurses/ncurses.faq.html

>>1038367 (OP)

>How can you possibly do it correctly?

Unfortunately, that depends on the particulars of your program, as there's many things that can go wrong with using a terminal emulator. What's the minimum column and line count it needs to properly display, for one, and how can it handle resize? To my knowledge, you can't tell the terminal emulator to resist a resize.

>I see things like menus (which are fine but what if I need multiline items).

Welcome to the wonderful world of edge cases.

>What about scrolling (not just down but also up)

What do you mean?

>What if I need to scroll not by lines, but by "items" like windows, or scroll horizontally

You'd need to build that abstraction yourself.

>I'm a minimalist fag, so I'd love for more TUI programs when appropriate, and it seems having something like this would be a yuuge help towards making TUI programs

What I did was build my own terminal abstraction library, ACUTE-TERMINAL-CONTROL; if you're using Common Lisp at any point, give it a try. There's someone building some abstractions over it, actually.

I'm not particularly familiar with the Ncurses API, but I don't like what I've seen. If you're really into minimalism, I suggest building your own abstraction or using a simple abstraction someone else wrote. Most every terminal is going to follow ECMA-48, so you don't need terminal control code abstraction anymore.

The only thing the terminals have over everything else is that at least they're simple. Anything on top of X11 isn't going to be. You may be surprised to learn that even the terminals are handled poorly; Xterm has several incompatible and broken mouse reporting modes, along with interpreting extended colors (That is anything beyond the eight defined by name.) incorrectly. Every other terminal emulator, it seems, just follows Xterm's mistaken lead, without even knowing the standards being implemented.

>>1038482

I've found support for sixels so poor that one may as well not bother.

>>1038570

>Is Ncurses really worth it when you have access to a real GUI? It seems like it's just as complex as traditional GUIs, just with worse capabilities and random limitations due to being console based. For basic modal dialogues and shit it's okay, but I see people trying to draw graphics with ASCII art and it just looks fucking retarded.

The terminal is the only thing supported well. Everything else is even worse. I've not seen a single X11 GUI that isn't disgustingly complicated, is documented well, is supported by the languages I need, is still maintained, along with other issues. I've given up on that.

>The problem with GUI libraries is they always want to be an enterprise-ready library that lets you customize and modularize every single thing about your GUI so that you can actually make real, professional programs with it like Office or whatever the fuck. But 90% of the time you're working on a small project and you're not gonna use use 90% of those features, and they create complexity up front because now basic things are more complicated than they need to be. I wish there was a library that is deliberately limited in how powerful or customizable it is, as a trade off to allow minimal effort GUI for prototyping/hobby projects. If I ever make the app mature enough to sell, I'd just hire a real GUI programmer.

This is also how I feel.

>>1038601

>UNIX weenie design.

Here it comes!

>Ncurses has an intentional memory leak

[Citation Needed] like ALL of your assertions in ALL of your posts.

>>1038476

I can assure you that w3mimgdisplay does not work in standard tty.

The effect shown is using a graphical tty, which has for some reason become the default in most distros.

>>1038661

Then, that's a framebuffer TTY. It's not that many distros are adopting it, it's just the linux's KMS in action.

I guess it only works on Intel, AMD and Nouveau drivers because they're open-source, if you're using Nvidia's proprietary driver, or you disabled KMS, you would see the traditional 80x24 terminal. In that, displaying pictures would not work.

>>1038676

your brain has a memory leak

>>1038676

As pointed out in >>1038609, indeed ncurses leaks memory, but not as accident or bad programming, but due implementation details and optimization.

The manual is really clear about it, it clearly instructs the programmer that it is intentional and provides a work around if needed "--disable-leaks".

Since such optimizations may not be needed anymore due to the high processing power we have today, maybe a new ncurses could be developed? Why don't you give it a shoot?

According to the Wikipedia's article about ncurses, programs like w3m uses it just for termcap. So if you don't use all the features, maybe you won't have leaks.

By the way, nice picture you got there, perfect strawman to throw around. Asking for proof is the same as rat kvetching.

>muh color characters in font

>muh emoji characters

>muh unicode too big and complex

>I have a great idea: let's abuse characters for GUI elements! I call it: TUI!

It's bullshit. Use GTK or >>1038436 or make your own minimal Wayland GUI lib.

>like an OS installer

If it's a desktop OS then no. Even Haiku offers a graphical installer in the form of a live DVD/USB stick/whatever you prefer.

Why install an OS you can't run? I know it costs more CPU power if the drivers aren't installed yet but I doubt the CPU will have a significant impact on the installation speed even on old devices.

>>1038589

Don't try to be a minimalist.

Minimalism is pure mental illness, depression to be specific. Don't fall for it.

Instead you should aim to use the best tool for the job. If it turns out some tiny image viewer is the best then use that but make sure that's true. Don't start using some gimped piece of ass because some guy with a 16gb RAM 500gb SSD Ryzen 7 or some shit is installing gentoo and talking about how st is way more minimal than xterm.

>>1038715

>Use GTK

Too much bloat.

>>1038724

Make your own Wayland GUI lib.

>>1038695

>using female pronoun on a person if indeterminate gender

>calling someone a faggot

Go back to your women's rights class.

Furthermore >>1038689 also made clear that it isn't bad design, but optimization. To prove bad design, you'd have to test the framerate impact of a change to what you'd consider better design, then determine the average percentage of memory of a modern computer wasted with percentage of computing cycles wasted and see if it comes out worse.

>>1038597

Different applications have different viability.

I wouldn't play games or browse the web in an ncurses setting, it just isn't possible.

Other stuff like file managers or even torrent clients do work though.

>>1038618

>Unfortunately, that depends on the particulars of your program, as there's many things that can go wrong with using a terminal emulator. What's the minimum column and line count it needs to properly display, for one, and how can it handle resize? To my knowledge, you can't tell the terminal emulator to resist a resize.

Yeah these are problems I'd have to think about if I were writing a program with ncurses. To have the library already resize the window would be amazing.

>Welcome to the wonderful world of edge cases.

It's still a case regardless. There should be support unless the case is really obscure and doesn't merit implementation.

What I'd do is at least support easy ways to implement that use case.

>What do you mean?

In ncurses, if you have a window, and you "fully write" to it, then writing more and refreshing won't do a thing. There's an option to "scroll the window" upon this happening, but all it does is scroll down. You cannot scroll backup I think, even if you move the cursor to (0,0) and refresh.

But I'm not so sure.

>You'd need to build that abstraction yourself.

Or have a library already supporting that. I don't want to concern myself with implementing irrelevant stuff.

>What I did was build my own terminal abstraction library, ACUTE-TERMINAL-CONTROL; if you're using Common Lisp at any point, give it a try

I'll check it out, but I won't lie, I'd rather it be written in Guile. I'll still check it out though.

>The only thing the terminals have over everything else is that at least they're simple. Anything on top of X11 isn't going to be.

This is why I like terminals to begin with. They're extremely simple and much more fun to work with.

> You may be surprised to learn that even the terminals are handled poorly; Xterm has several incompatible and broken mouse reporting modes, along with interpreting extended colors (That is anything beyond the eight defined by name.) incorrectly. Every other terminal emulator, it seems, just follows Xterm's mistaken lead, without even knowing the standards being implemented.

Even terminals like st and urxvt?

>>1038593

>libsixel

I'll check that out, hopefully my language already has a wrapping/binding for it.

>>1038716

This is already kind of my approach.

Not everything terminal is automatically good.

I would never browse the web with w3m or lynx, it seems impractical.

But I am biased towards the command line because I think it will by default mostly be better than GUI; of course there are exceptions.

>>1038676

>jews are the only ones that require proof for claims

Then prepare to listen and believe, if you're really white.

Ncurses does not have memory leaks.

The moon's made of cheese.

You are the smartest person on Earth.

Windows is objectively better than an avocado.

2+2=the sum of the squares of the hypotenuse

Moose estivate yearly.

Anyone you disagree with is a jew.

For more information, please consult http://timecube.2enp.com/

>>1039542

>it seems impractical

this is the problem with your "best tool for the job" approach. Your sorting function is extremely dependent on your personal experience. What's "best for the job" will always be the most plebian and consumerist of shit, because anything else will have a speed bump in front of it, and that will make it "seem impractical".

>>1039545

Whereas your metric of most obtuse = best leads to using a text based interface to view images. Pure insanity.

>>1038436

>>1038570

I primary use ncurse because of ssh and tmux, I use my netbook to access my tower in the closet because I can't stand the fan noise. I know I can forward gui through ssh but that's a bit clunky and slow. Is there a better solution?

>>1039547

>most obtuse = best

I criticize a personal-experience-dependent metric, and you accuse me of having one as well? Or did you not even think about how one would even be able to determine what's "most obtuse" out of some options?

Minimalists have numbers.

>>1039550

>Minimalists have numbers.

lol like LOC yeah totally not subjective.

>>1038436

This is bait but you are right. Don't use Ncurses as its heavyweight because of legacy code. Something like blessing would be better even, and that's with python being shit. Just implement the line draw to /dev/fb* and keyboard input yourself. VLC has an implementation too if you need another reference on how its done.

>>1039573

Hello World! Greatest software of all time. Side note, GNU Hello= Enterprise Fizz Buzz. Actually, this whole loc metric isn't so bad, as long as you compare in category.

>>1038676

the good half of ncurses could be done in 200 lines of c

>>1039584

How many CVEs would it have though?

>>1039585

>200 lines of c

you could audit it in about 30 seconds

CVEs come from too much code, not too little. Look at the list of CVEs for classic c programs like curl. They're all in the obscure, recently added parts that no one ever uses.

>>1039545

But let's face it, using w3m or lynx isn't practical, specially if you have to use school websites, where javascript is required.

>>1039587

>200 lines of C are easily audited

Top LARP!

http://port70.net/~nsz/c/c99/n1256.html#J.2

>>1039539

>Yeah these are problems I'd have to think about if I were writing a program with ncurses. To have the library already resize the window would be amazing.

They're problems with writing a program that works with a terminal emulator at all. It would be so nice to be able to specify minimum dimensions, as GUIs can, but this is just one of many things that aren't accounted for.

>It's still a case regardless. There should be support unless the case is really obscure and doesn't merit implementation.

>What I'd do is at least support easy ways to implement that use case.

I agree. I'm of the opinion that every edge case should be accounted for.

>In ncurses, if you have a window, and you "fully write" to it, then writing more and refreshing won't do a thing. There's an option to "scroll the window" upon this happening, but all it does is scroll down. You cannot scroll backup I think, even if you move the cursor to (0,0) and refresh.

That's odd, but I'm fortunately rather ignorant of much of Ncurses. The ECMA-48 standard supports scrolling the entire terminal in the four directions, so everything works best if you can fit it within that model.

>Or have a library already supporting that. I don't want to concern myself with implementing irrelevant stuff.

I can't write that I'm fond of these virtual windows and whatnot, anyway. I'd rather have a more pleasant interface that is also easier to program correctly.

>I'll check it out, but I won't lie, I'd rather it be written in Guile. I'll still check it out though.

In case you've not already found it, here:

http://verisimilitudes.net/2018-04-04

>This is why I like terminals to begin with. They're extremely simple and much more fun to work with.

Keep in mind that being simple doesn't mean pleasant to program. It's simpler that a terminal doesn't let you lock dimensions, as an example, but this makes it much worse to program for.

>Even terminals like st and urxvt?

Read the comments in my ACUTE-TERMINAL-CONTROL for my full thoughts, but yes. As an example, they don't even implement ISO 8613-6 colors correctly, these being colors beyond those predefined eight referenced by name; they improperly parse them and so you have the option of sending a slightly incorrect sequence or not using the colors at all. I sent a (poorly written) patch to the st developers, but they didn't even care.

Of course, you must find this out for yourself. It's not as if st or any of these terminals actually know they're following the ISO 8613-6 standard. They just do whatever xterm does. It's a mess.

>>1039602

Yes, you have to know the c programming language in order to audit it. Compared to a full language definition - including standard library - that list is pretty short. If only you were just auditing for unspecified behaviour!

>>1039596

no, w3m's a superior browser for many purposes.

>>1039573

>LOC yeah totally not subjective

LOC is a lot of things but 'subjective' isn't one of them.

>order these men by height

<height? that's subjective!

>uh, no it isn't

<watch me cut the legs off the taller men. see? they're shorter now

>>1039635

>

ex +'%j|x' mysource.c

>look my source code is a single line

>>1039639

this is akin to crouching and saying you're shorter

you're dumb and your smart ass responses don't change the fact the LOC is a real metric by which to judge programs

>>1039615

Honestly, it's mostly the scrolling thing I have a problem with.

If your library can already scroll in all directions then it's already better than ncurses.

I'll definitely check it out.

Emacs. Literally Emacs.

>>1039646

I know you are baiting but here's a you anyway.

>>1039548

> I use my netbook to access my tower in the closet because I can't stand the fan noise.

ummm,,,

if your PC can run in a closed closet, then it isn't so hot that it needs turbojet fans

and with most PCs, you can use a fan-mate to slow the fans down to about 60% speed, and lose about 90% of the fan noise

-----

as to OP: primitivism for its own sake is not a virtue. 'Less' is never 'more'.

>>1039736

it's not bait. LOC is LOC and pretending it's meaningless because it can be manipulated is just pretending to be stupid.

>>1038676

>only kikes ask for proof

>only cis white males ask for proof

Spot the difference, stormnigger

>>1039770

I wrote less words than you. Therefore my post is better. Face those facts.

>>1039619

>that list is pretty short

Nice damage control, cnile.

>>1039815

Both of our posts are under 1KB. Nobody cares.

It's easier to pretend to be stupid about numbers if you forget how people actually use them, huh.

>>1039573

>>1039639

Lines of code is a really good quantitative indicator of complexity.

You can artificially bypass in a (dumb) way like you did, but that can be done with any indicator whatsoever. Like some time ago one study said women were as "gamers" as men because they included 5 minutes of candycrush as being a gamer.

Really, you sound like you're bitching just for the sake of it, just to be contrarian and pretend to be smarter than everyone else.

>You guys using unix a judging complexity with LOC, so silly and outdated.

>>1039770

The standard I use is GFLOC - Good Faith Lines Of Code

If the author isn't being a retard making the code shorter in stupid ways then you can measure it in GFLOC.

>>1039815

nigger

>>1039633

ok kid

>>1039884

Smart terminals, the ones that you can change the cursor position, font weight, have an alternate screen and other features, predates GUIs.

https://en.wikipedia.org/wiki/Computer_terminal#%22Intelligent%22_terminals

Even late Multics used the smart terminal features (the Multics faggot actually made curious about it):

https://multicians.org/terminals.html

ncurses carries a lot of baggage due to compatibility to a lot of models and I don't know if there's a minimalist approach to it. Basically, today we mostly use xterm-256, so I think a developer can get away just handling this terminal.

>>1039884

The whole concept of the GUI is just fundamentally broken. It's centered around the idea that a person should want to do six different things at once, so you need to have six different windows open. CLI programs, and therefore TUI programs, recognize that most of the time you only need one program open, to do one thing. If you need to do something else, you should pause the first task, or background it, and move to the second task. But the default is to do one thing at once, as it should be.

>>1039918

You're an idiot, the GUI is centered around the idea that you can present multiple options on a screen and make the functions of a computer more transparent.

Instead of looking into the void of a terminal and having to know the magic words, you have options presented to you as icons. You click one and it expands into further options, a file menu, a url bar, etc.

>>1039918

Imagine if you had to type "READ_COMMENT 0xFDE2E" to use this website. It would have no userbase.

>>1039895

Interesting, but modern terminal emulators do the same thing. I'm looking for the modern equivalent for the BLIT terminal.

>>1039918

>recognize that most of the time you only need one program open

What's the point of a multi-tasking operating system then?

>>1039924

Correction: it would have no normalfags.

>>1039895

>ncurses carries a lot of baggage due to compatibility to a lot of models and I don't know if there's a minimalist approach to it. Basically, today we mostly use xterm-256, so I think a developer can get away just handling this terminal.

What sucks about ncurses is that it's based on emulating character-oriented terminals because the PDP-11 they were using had a teletype instead of a CRT. GUIs are a huge hack on UNIX, but so are terminals. This means every single keypress causes multiple context switches, leading to kludges like having intentional memory leaks for "speed" and similar bullshit (including but not limited to the typical C brain damage), while still being slower and using many orders of magnitude more memory. In contrast, "By ensuring the CPU is not interrupted at every keystroke, a 1970s-era IBM 3033 mainframe with only 16 MB was able to support up to 17,500 3270 terminals under CICS."

https://en.wikipedia.org/wiki/Computer_terminal

>The POSIX terminal interface, as provided by Unix and POSIX-compliant operating systems, does not accommodate block-mode terminals at all, and only rarely requires the terminal itself to be in line-at-a-time mode, since the operating system is required to provide canonical input mode, where the terminal device driver in the operating system emulates local echo in the terminal, and performs line editing functions at the host end. Most usually, and especially so that the host system can support non-canonical input mode, terminals for POSIX-compliant systems are always in character-at-a-time mode. In contrast, IBM 3270 terminals connected to MVS systems are always required to be in block mode.

https://en.wikipedia.org/wiki/Block-oriented_terminal

>Block-oriented terminals have the advantage of causing less system load on the host and less network traffic than character-oriented terminals. On a multi-drop line there is considerable overhead for each transmission which is the same for a single character as for thousands of characters. Block-oriented terminals may also appear more responsive to the user, especially over slow connections, since editing within a field is done locally on the terminal itself rather than depending on echoing from the host system.

https://en.wikipedia.org/wiki/IBM_3270

>The 3270 series was designed to connect with mainframe computers, often at a remote location, using the technology then available in the early 1970s. The main goal of the system was to maximize the number of terminals that could be used on a single mainframe. To do this, the 3270 was designed to minimize the amount of data transmitted, and minimize the frequency of interrupts to the mainframe. By ensuring the CPU is not interrupted at every keystroke, a 1970s-era IBM 3033 mainframe with only 16 MB was able to support up to 17,500 3270 terminals under CICS.

    Actually, it's more the hardware vendors fault.  For
about 15 years now, the solution has been to throw more
hardware (memory, cpu cycles, graphics co-processors, and so
on) at the users.  UNIX has the dubious advantage of looking
more like "a real operating system" to the microprocessor
crowd (who are used to CPM/MSDOS/etc).

    So they think that by installing unix, it makes their
system into a "real computer".  In fact, unix is just a
minicomputer operating system (at best).  So what they end
up with is a box with more MIPs than a 70s mainframe, more
memory than a 70s mainframe, more disk than a 70s mainframe,
and a 70s minicomputer operating system.  And it runs about
as fast as a 70s minicomputer, asn supports as many users.

The wonder is that anyone is surprised.

>>1039923

>Instead of looking into the void of a terminal and having to know the magic words, you have options presented to you as icons

TUIs can do that as well. The people who originally developed GUIs had access to these TUIs, and were trying to go beyond them. What they came up with was a schizophrenic array of floating windows, where a person can be doing any number of things at one time. Look at any of the old demos, and this is what they are showing off. Telling the user what they could do was old hat.

>>1039932

>what's the point of a multi-task operating system then?

Obviously any given program can take advantage of multiple processes, eg for parallel builds. And you need mulltitasking to implement time sharing. But the key word is "most of the time", there are choice situations that call for background processes.

>>1039937

this

>>1039939

based

>>1039924

BBSs existed before GUIs, and they were massively popular.

Stop being retarded.

>>1039992

BBS also have no userbase. Are you sure you're not also being retarded?

>>1039994

There's, like, two posts on /dqn/ daily. There are a couple of active textboards. Also a bunch of /prog/ spinoffs.

>>1039918

>so mind fucked he actually uses the equivalent of a super computer to read text

>>1039943

>TUI

>muh arrow keys

lol

>>1040080

who are you quoting?

>>1040102

cuckchanner begone

>>1038618

Okay, I checked it out. I'm confused regarding your last pararagraph the page.

Care to explain what you mean by needing to launch the CL implementation with another program.

>>1040386

>Care to explain what you mean by needing to launch the CL implementation with another program.

I mean one should, ideally, abstract the Common Lisp program from the wants of the underlying operating system.

Here is an example of me doing this:

http://verisimilitudes.net/mmc-chip8

This sh program handles any recognized command line arguments, sets the terminal state to no buffering nor echoing, handles restoring terminal state to what it was once the program is finished, and you can see at the end it launches the Common Lisp implementation selected with the actual program.

So, this sh program handles all of the UNIX drudgery for me, allowing the Common Lisp to be better and free of such concerns.

>>1040493

So, in short, this functions the same as ncurses's endwin()?

>>1040565

>So, in short, this functions the same as ncurses's endwin()?

I wouldn't know. I lightly looked around for documentation, but found none that told me what this is.

Think of it like this: UNIX uses the sh program and if I ever were to find myself using this program on a different system, I'd simply need to write another program in the system's preferred language to accomplish the same or similar goals there.

>>1038618

>AGPL

Disgusting.

>>1039550

A personal-experience-dependent metric is the only kind of metric that is of any use here. No matter if it's the decision what you use personally or what library, like ncurses, you use for your project, you'd be stupid not to just do it the way you personally like best when you have the chance to do so.

Also keep in mind that you need graphics to display graphics.

>>1040793

termbox is classical minimalism in that it has less features for no real reason other than it'd be bloat.

>>1040793

can I read user input without enter with termbox?

>>1039918

>The whole concept of the GUI is just fundamentally broken. It's centered around the idea that a person should want to do six different things at once

Lol no it's not you retarded faggot

If you want to write anything GUI related, first understand Model-View[-Controller] paradigm.

Maybe start with some graphical gui creation toolkit like Qt and see how it is handled there.

For scrolling text you just need a struct that holds all lines and an int for current index.

And a function so the GUI can request a certain number of lines starting with the selected one for display.

>>1046348

>lines

lol

>>1039939

>s fast as a 70s minicomputer, asn supports as many users.

Your so full of absolute utter bullshit. Just because something is old doesn't make it bad. Engineering is not done by replacing everything they people 10 years before him did with a completely different thing every few years. It's done by building atop of and refining what we have already built. This is why userspace is suck a mess. Because every webdev who think's he's hot shit because he can he can make a Wordpress plugin thinks he know's better than 40 years of computer engineers did. Then you get shit like PulseAudio and systemd

>>1047112

systemd a dbus

>>1047112

>Just because something is old doesn't make it bad.

Exactly, which is why "a 1970s-era IBM 3033 mainframe with only 16 MB was able to support up to 17,500 3270 terminals under CICS."

>Engineering is not done by replacing everything they people 10 years before him did with a completely different thing every few years.

UNIX weenies in the 80s were saying it's better because it's newer, now they say it's better because it's old. Why is it that UNIX weenies have no respect for anything old or new unless it's UNIX? UNIX weenies want to replace everything with UNIX bullshit that can't even parse strings without crashes and remote exploits, not to mention that everything needs tens of times as much code just to be buggier, slower, and less reliable. Instead of hundreds of megabytes of libraries so you can pretend UNIX sucks less, a good operating system works right from the ground up.

>It's done by building atop of and refining what we have already built. This is why UNIX is such a mess. Because every weenie who thinks he's hot shit because he can make a shell script thinks he knows better than 60 years of computer engineers did. Then you get shit like UNIX and C.

If you want to improve something by refining and building on top of it, it has to be good in the first place. UNIX and C took a huge shit on computer engineers who were developing improved hardware. Webdev is just more UNIX bullshit written in UNIX languages. All these fragile hacks like parsing text error messages instead of using error codes or objects came from UNIX. What really sucks is that programming has been corrupted by UNIX bullshit so much that weenies think these hacks and workarounds like EINTR are how computer engineers actually intended their hardware to be used.

These people are seemingly -incapable- of even believing
that not only is better possible, but that better could have
once existed in the world before driven out by worse.  Well,
perhaps they acknowledge that there might be room for some
incidental clean-ups, but nothing that the boys at Bell Labs
or Sun aren't about to deal with using C++ or Plan-9, or,
alternately, that the sacred Founding Fathers hadn't
expressed more perfectly in the original V7 writ (if only we
paid more heed to the true, original strains of the unix
creed!)
                                                   
       In particular, I would like to see such an article
   separate, as much as possible, the fundamental design
   flaws of Unix from the more incidental implementation
   bugs.

My perspective on this matter, and my "reading" of the
material which is the subject of this list, is that the two
are inseparable.  The "fundamental design flaw" of unix is
an -attitude-, and attitude that says that 70% is good
enough, that robustness is no virtue, that millions of users
and programmers should be hostage to the convenience or
laziness of a cadre of "systems programmers", that one's
time should be valued at nothing and that one's knowledge
should be regarded as provisional at best and expendable at
a moment's notice.

My view is that flaming about some cretin using a
fixed-sized buffer in some program like "uniq" says just as
much about unix as pointing out that this operating system
of the future has a process scheduler out of the dark ages
or a least-common-denominator filesystem (or IPCs or system
calls or anything else, it -doesn't matter-!)


The incidental -is- fundamental in dissecting unix, much as
it is in any close (say, literary or historical) reading.
Patterns of improbity and venality and outright failure are
revealed to us through any examination of the minutiae of
any implementation, especially when we remember that one
cornerstone of unix pietism is that any task is really no
more than the sum of its individual parts.  (Puny tools for
puny users.)

>>1038476

>ranger

RIP

>>1047223

Based.

>>1038538

bamp for answer tbh.

>>1039939

>>1047223

>offload more stuff to the terminal

>WOW NOW MY MAINFRAME CAN HANDLE MORE CONNECTIONS

>UNIX BTFO

>>1047533

check out the environment variable LANG.

Try export LANG=en_US.utf8 before running your package manager.

Also try setting LANGUAGE=en_US

LOL, I wish I thought of doing that!