Here we go, some more basic functions:

http://arsdnet.net/dcode/terminal.d

The unix stuff is more implemented than the windows.


Let's walk through main and I'll discuss why I'm doing things the way I am. I'm throwing this out just to show one possible way this can be done and to explain why I like this way. Feel free to take some or all of my code if you want.


        auto terminal = Terminal(ConsoleOutputType.cellular);

First, the terminal is a separate type, a struct, rather than just magic functions. This way it can use the struct destructor to reset things to normal.

The argument here is either linear or cellular - do you want line based output or do you want to control the whole screen as a grid of cells?

If you use cellular, it will use the alternative screen buffer on unix terminals. IIRC Windows works basically the same way. This is what we want for a TUI app.

The escape sequences to make this happen is based on the envrionment variable TERMCAP, which is set by gnu screen, xterm, and most other emulators.

It is *not* set by the linux console or rxvt on my box, so this isn't perfect yet, but it is a start. If it can't find a capability in there, it simply ignores those method calls, meaning it should be backward compatible (once fully implemented - I haven't done this on title yet.)

        terminal.setTitle("Basic I/O");

All changes are done with methods. This is how Windows does it and is cleaner anyway.

        auto input = terminal.captureInput(ConsoleInputFlags.raw);

To get real time input, you use a special method which returns an input struct. Which could probably be an input range actually but isn't now.

Anyway the reason is you have to change the terminal mode in linux to get real time input. Otherwise it will be line buffered. Again, a struct lets us reset the mode automatically in the destructor. The flags let you control automatic echo.

        terminal.color(Color.green | Bright, Color.black);

I insist that you set foreground and background colors together. This ensure you get readable text.

The colors are defined with a platform independent color enum and you can flag in bright to get brighter colors.


BTW I'm thinking about calling it LowContrast instead of bright... then your color definitions can always be the same regardless of bg, and it automatically flips the bright bit if needed. But since I'm forcing you to specify background here too it isn't a big deal with now.


        int centerX = terminal.width / 2;
        int centerY = terminal.height / 2;

I prefer width and height to rows and columns. I think more in terms of gui here.

        while(true) {
                if(input.kbhit()) {

Since we have real time capture, can poll for new input instead of blocking.

                        auto c = input.getch();

Get our character... (BTW this function still needs a lot of work)

                        if(c == 'q' || c == 'Q')
                                break;
                        terminal.moveTo(centerX, centerY);
                        terminal.writef("%c", c);
                        terminal.flush();

And output the stuff, centering the text. All output methods are attached to the terminal to ensure the proper api stuff is handled.

                usleep(10000);

This is just there so we don't eat too much cpu waiting on input.

Reply via email to