Julien,
The issue that fons brought up regarding mixed output lines does
raise another question: what do you do with programes if you have
problems? I take it most devo's want debug output, how do you get
it to them with your display?
Bristol has an option to redirect debug to a file, I think I might
see about getting that to work whilst having the CLI use another
file descriptor which is a dup() of the original stdout.
Nick.
"we have to make sure the old choice [Windows] doesn't disappear”.
Jim Wong, president of IT products, Acer
From: nickycopeland@hotmail.com
To: fons@kokkinizita.net; linux-audio-dev@lists.linuxaudio.org
Date: Fri, 9 Apr 2010 23:07:23 +0200
Subject: Re: [LAD] Interface development for the blind (starting from Bristol)
> you want the user's input line to remain intact
> instead of being broken into pieces by the output.
> This could be even more important in case the
> interface is a single line Braille 'display'.
>
> I once had some nice code solving this, but it
> was written for my then employer, and I can't
> use it in open source projects.
That is a good point. A text based interface is quite an abtraction
of something that has been written to be a GUI which means
debug output may well be useful. Since that does damage the
display, with or without brail, it does beg the question as to whether
it could be 'rewritten'.
It could be done with some IO redirection pipes, suitable code in
the 'raw' IO channel to understand where input came from using
a bit of extra select() in there to bring the channels back together
and apply suitable output depending on where the different CR
were, or that incomplete user input lines were rewritten after
each debug line? And then a bit of NL->CRNL for the raw mode
interface.
Not something I would want to code for a prototype but is
unfortunately something that could better be coded in advance
than bolted on the end?
Nick.
Hotmail: Free, trusted and rich email service. Get it now.
Hotmail: Trusted email with powerful SPAM protection. Sign up now.