On Tue, 22 Sep 2009, Samuel Thibault wrote: > Nicolas Pitre, le Tue 22 Sep 2009 16:59:23 -0400, a écrit : > > On Tue, 22 Sep 2009, Samuel Thibault wrote: > > > Nicolas Pitre, le Tue 22 Sep 2009 13:32:40 -0400, a écrit : > > > > On Tue, 22 Sep 2009, Samuel Thibault wrote: > > > > > Yet another person on the NVDA list wanted to re-implement a driver > > > > > for > > > > > some braille device because he doesn't want to have to run both brltty > > > > > and nvda at the same time. > > > > > > Various reasons such as additionally mentioned in my other post > > > http://mielke.cc/pipermail/brltty/2009-September/006118.html > > > having to deal with starting/stopping two daemons at a time. > > > > You're kidding or what? Or maybe Windows is such a strange environment > > that starting/stopping daemons is such a big deal? > > For a casual user, it is.
I think I'm not making myself understood. For a _human»_ user having to manually start BRLTTY beforehand is stupid. Ideally, NVDA should take care of starting/stopping BRLTTY itself. An even better solution would consist of BrlAPI taking care of starting/stopping BRLTTY as needed instead, so that knowledge is localized and shielded from BrlAPI users. > > > Yes, but they don't start a service that may completely steal the screen > > > output and interfere with the VGA driver just because one has opened a > > > command line window, which is equivalent to what currently happens after > > > having installed brltty while jaws is installed. > > > > This is of course a bug with BRLTTY. One shouldn't have to relinquish > > the screen output because BRLTTY is starting only to serve BrlAPI > > requests. > > > > In fact, I'm actually thinking that any BrlAPI user shouldn't have to > > deal with starting BRLTTY at all. Instead, it should be BrlAPI's > > responsibility to start/stop BRLTTY itself as needed and shield the > > necessary mechanic from BrlAPI users. This way you have a single API > > and behind the scene it could well be possible for BrlAPI to actually be > > linked with BRLTTY without having a separate process, or be a separate > > process with a communication pipe, etc. In any case it is a bit silly > > for BrlAPI users to have to know how and when to start (or not start) > > BRLTTY. > > This is _already_ what happens. When no BrlAPI client is connected, > BRLTTY doesn't take control of the braille device. When a windows > command line is opened, however, BRLTTY acts as a reader for it. A > solution could be to disable command line screen reading completely by > default. Not a good thing for people using it as a command line screen > reader, but maybe we can consider that those are able to re-enable it. > > Now, another issue is "portability" in windows terms: users want to be > able to throw nvda+brltty on a USB key and easily start them on any > computer after just plugging the key in. Yes, they could just start > brltty and then NVDA, but apparently it's still some blocker for casual > users. NVDA could start BRLTTY itself, of course, but James is reluctant > to do that due to the potential issues it could bring. Hence my assertion that BrlAPI should be the agent taking care of that. > > And a braille library won't solve anything either. > > Indeed, but it will makes things simpler to deal for the user: two > applications using the same device. Close one, run the other, or > vice-versa. And not a service to start/stop. Yes, considering that when > NVDA is stopped BRLTTY shouldn't harm, it shouldn't be a problem but I > still see reluctancy from windows users. See above. > > Should be possible to configure compilation of BRLTTY+BrlAPI to > > achieve just that without having to write interface code. > > You mean by using something like a pipe inside the process itself, on > which the BrlAPI protocol will flow? Exact! For small environment you configure BrlAPI+BRLTTY like that, which effectively becomes a library. For other environment with concurrent "clients" you configure BrlAPI+BRLTTY in a client/server model. In both cases the same API is used and the clients don't need to make a difference. Nicolas
_______________________________________________ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: [email protected] For general information, go to: http://mielke.cc/mailman/listinfo/brltty
