Last Week in NVDA (20 Oct)

The major addition to braille support last week was support for the review cursor. Braille can now be tethered to either the system focus/caret or the review position. When tethered to the review position, the display is updated when the review position changes and the routing keys move the review position if appropriate. Unfortunately, there is currently no user friendly way to change this tether mode; it must be done via the Python console. This will be resolved some time this week. Aside from review support, if a change occurs to an object which is being displayed, the display will be updated accordingly. I also added the ability to display messages which time out after a short period. These messages can be dismissed immediately by pressing a cursor routing key. Scrolling the display left or right causes the timeout to be reset to provide more time to read the message. Many of the scripts in the default appModule, such as NVDA+f12 to read the time/date, now display their messages in braille as well as speaking.

Braille display support is still being developed in a separate branch of the code. It has been difficult to decide when this code should be merged into the main NVDA code. There is still a lot of work to be done and BRLTTY is still quite difficult to set up for most users. On the other hand, there are no serious issues with the current code and I would like it to be tested as much as possible. Mick and I discussed this question at length last week. We decided that the current code will be merged as soon as a couple of issues are resolved. The first is to stop computation of braille when there is no braille display in use, as this is pointless and inefficient. Second, there needs to be a way to switch the cursor to which braille is tethered as discussed above. I will hopefully resolve these issues and merge braille support this week.

Mick's agonising endeavours with the virtual buffer library and RPC continue. We spent some time deciding on how RPC will fit into the library's architecture, as well as determining the programming interface for the library. Unfortunately, rather than Mick being able to dive straight into the implementation as we had hoped, he discovered some very frustrating problems. In technical terms, it seems that if you statically link the C/C++ runtime (which is what we have done previously), you cannot safely manipulate objects from any other dll other than the one in which they were created if they are managed internally in some way by the C/C++ runtime, even though the dlls might be dynamically linked. This probably includes most standard C++ classes and templates. The reason is that when the runtime is statically linked, a separate copy of the runtime is used and each maintains its own internal state separately. This was causing many seemingly random crashes and took quite some time to debug. This isn't a problem if all relevant dlls and applications are dynamically linked against the same runtime. However, this requires that the process into which we are injecting has access to the required runtime dll, which cannot be guaranteed because NVDA might be running portably and thus can't copy files to the Windows system directory. The only solution for us is to statically link the runtime and avoid passing such objects between dlls. If you didn't understand any of this (I bearly understand it myself!), suffice it to say that this is yet another exasperating, convoluted hurdle in a seemingly endless series of such hurdles. Nevertheless, we'll get there... eventually. :)

There were only a few minor changes to the main NVDA code last week:

The hack fest I mentioned last week will happen from 9 to 14 November. We haven't yet written an action plan for this.

Comments

No comments.