Question about user interaction with Curses

[meLlamanJefe]

I have a C++ application that instantiates various instances of the same object (let's call it MainExec) and puts them into a vector. Each instance of a MainExec runs in its own thread. The code was originally written to run only one instance (thread) of the MainExec object and it uses Curses to interact with the user. The Curses session runs on the same physical terminal screen where the program was executed in and is used to read user commands and display output states.

Now that the code is being expanded to run more than one MainExec object at one time I am wondering if it is possible to have each MainExec thread spawn or create/open a new physical terminal screen to launch its Curses session so the user can interact with each instance separately but can also monitor them all at once. So if the program is told to run 4 instances of MainExec then I would like to get 4 different physical terminals on the computer monitor.

Is this possible and does anyone have example code if this is the case?

Thanks.

-Marco

[RRick]

Curses appears to work with a single terminal (or tty in unix speak). You can create new windows that sit on top of other windows, but all of these windows use the same tty. With this layered approach, a single program could create threads to deal with each window instance. You would also need some mechanism to switch between windows.

The more common use of curses is a new term program for each window. The only way (I know of) to attach to these windows is by starting a new and separate program with each terminal. Say good-bye to the threaded approach. If there is some program watching all of these processes, you are going to need some way to communicate and that means using interprocess communication like sockets, pipes, files, etc.

In either case, this doesn't sound like a simple thing to do.

[donbock]

Do you have the source for this curses? I implemented a version of curses for our embedded product a few years ago and found it wasn't very hard to add in a multiple-tty feature while I was at it.

Does your target operating system support multi-tasking such that each task can have a different stdin/stdout? If so, then spawn off each instance to its own task and redirect stdin/stdout to the appropriate physical terminal screen. As I recall, curses prefers to deal with stdout and stdin.

When you say "new physical terminal screen" do you mean several actual physical monitors?

[meLlamanJefe]

Sorry for the late reply. Thanks for taking a look at my question. I am developing on a linux system (RH Enterprise 5, x86) so I can certainly download and modify a copy of curses that I can use for my project. I have very little experience in this so I would appreciate some pointers regarding your suggestion. It also sounds like spawning a task would be an acceptable solution to my problem. I don't have to keep the application multi-threaded, that was just a proof of concept and we can change it if we find a better way. I also have no experience with how task spawning works so if you can point me to some examples or documentation I would really appreciate it.

As far as your last question, when I say "new physical terminal screen" I am not necessarily referring to separate monitors but rather separate windows within X where each window has its own terminal emulator. (Hope this makes sense).

-Marco

[donbock]

In curses, a single 'screen' can have multiple 'windows', but each 'window' belongs to exactly one 'screen'.

In traditional curses, the initscr() function initializes the single screen supported by curses based on the TERM environment variable.

I vaguely recall hacking curses in order to add support for multiple screens. I accomplished this by creating a variant of initscr() that accepted an argument. I had to make changes to the data structures to support multiple screen objects. I switched between screens by changing the value of a current-screen global variable -- because the vast majority of the standard functions assume they know which screen you mean.

The other alternative is to spawn off multiple tasks, each with a different TERM environment variable.