Hi Kirk - No question about it, the DOS environment is a piece of cake compared to the Linux environment. I am not at all unhappy with the way speakup handles things right now, and I have also learned a few work arounds that make life easier. Even in a single process system like DOS, the timing problem is not easy. The longer you wait to allow the screen to react to the keystroke, the more sluggish the speech; but the faster you make it, the more errors you get. Then there is the situation where the user is connected via a modem program to a remote system, and the timing gets totally out of control. And those problems are on simple systems. I mostly wanted to emphasize the distinction between cursor tracking, which as far as I know speakup has always done flawlessly, and speaking what the cursor travels over, which is an entirely separate problem. When I work in pico to edit a text document, I usually do my traveling with the review cursor instead of the true cursor, and when I find something I want to fix or change, I use the pico search function to bring the true cursor to the point of interest. I have no problem living with the current state of affairs. There are so many other things that speakup offers that I have no hesitation at all in opting for 1.0. BTW - Did you know that the very first release of the landmark data base program "d base" was called "d base II?" There never was a "D Base 1." Ashton Tate was convinced that people would have more confidence in a product with a "II" after it. Thanks for all the great work on a fine product. Chuck On 29 Sep 2001, Kirk Reiser wrote: > Hi Chuck and all: Well let's talk a tad about the difficulty of > automatic speaking of cursor movement. In dos and windows the screen > review program only has external access to the data as in interrupt > hooks or an os api. At first glance you would expect that if you have > total control at the kernel level you would be laughing, right? > Wrong. The kernel is absolutely not a sequential device as in you get > the key, you track the key, the screen handles the key, you say the > key. Everything is handled through a series of interrupts which does > very fast rudimentary handling of the event and then schedules on a > bottom-half queue. Okay, so what is a bottom-half queue. It is a > routine which runs after the interrupt has happened by a timer. It > keeps close attention to how much time is is using and reschedules if > the jobs are not all handled. At the same time all of the standard > processing is also going on as normal. As you can see we have already > induced asynchrony in the process. This also happens with our > output. So to cut to the chase, when identify the keystroke we don't > necessarily have any idea to when the exact time that keys event is/was > handled by the output routines. So you track the cursor say what is > on the screen at that point and woops, the screen hasn't even got > close to making that change. You just did the wrong thing at > absolutely the right time, wrong time, well which was it? So, maybe > we want to be smart about it and set our own timer. Okay, when? How > do we know whether we're saying the correct event or not? > > I do not believe this is an insermountable problem. I know however it > will take more examination of the system as a whole and I've already > spent extensive time on it. The truth of it is I don't know myself > the best way to handle it. So if you don't know, you put it aside and > work on the myriad other things which need to be done and come back to > the problem later. Meantime you hope you gain a better understanding > on a clear way to handle the problem. > > If someone thinks they can jump in and do a better job of it than me, > please don't hesitate to step up and fix it right. Until I have a lot > of other things finished it has moved way down on the priority list. > It tracks perfectly. It speaks correctly some of the time, and that's > all it will do for now. > > BTW Chuck, it works worse under emacs than under pico or any other > editor because emacs has an anoying habbit of bouncing the cursor all > over the place whenever it crosses a tab-stop position. When I'm > editing I almost always have speech output turned off with ins-enter. > It tracks perfectly then and I don't really care whether it speaks > every char or line. I am very familiar with where the review keys are > and I use them when I want feedback. > > Kirk > > Visit me at http://www.mhonline.net/~chuckh The Moon is Waxing Gibbous (94% of Full)
