bug-ncurses
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: filter() prevents clearing of screen, but still clears current line


From: Christer Enfors
Subject: Re: filter() prevents clearing of screen, but still clears current line
Date: Mon, 19 Mar 2007 11:38:00 +0100
User-agent: Thunderbird 1.5.0.10 (Windows/20070221)

Thomas Dickey wrote:
What I had in mind was making instring/outstring hide the details of how
they are interacting with the server.  The point of a server is that it
would be the only process to actually update the screen, so the problems
with clearing parts of the screen would just go away (unless there are
_other_ parts of the scripts that write to the screen - that would make
it not a good solution).
Right, that's how I would do it too. I don't think there are other 
things than instring / outstring that writes things on the screen. That 
would, as you say, ruin the setup.
But the first problem with this approach that I see is that it won't 
know when the legacy script is "done", so it won't know when to quit, 
and thus it won't know when it's time to "start over" - when a new 
legacy script is called, with another form.
Or... perhaps... if the first call to instring / outstring would trigger 
the starting of the server, and inform the server of the PID the legacy 
script has. Then the server could monitor that PID, and when the legacy 
process dies, the server dies too.
This reminds me of that university where the CS department kept a teddy 
bear. Students weren't allowed to ask the teachers for programming help 
until they'd explained the problem to the teddy. It turned out that 
around half of the students figured the problem out by themselves as 
they were explaining it to the teddy, thus reducing the number of 
students that had to ask a teach for help.

But the whole setup still feels kinda shaky. If it turns out that one of the legacy scripts use something other than outstring and instring to manipulate the screen, then everything would come crashing down.
However, there's another simpler approach too. I could dump ncurses all 
together for instring (which reads the input fields), and make a custom 
program for that, using scanf. I'd still use tput to move the cursor to 
the correct position on the screen, then I could just use a small binary 
that calls scanf(). But that problably won't work very well with arrow 
keys and whatnot. So I'd have to use libc's equivalence of getch() 
(whatever that's called), and handle things like backspace and arrow 
keys myself. That doesn't sound like fun.
Decisions, decisions!

--
Christer Enfors





reply via email to

[Prev in Thread] Current Thread [Next in Thread]