Log what is being displayed on the braille display.

[nvaccessAuto]

Reported by orcauser on 2012-02-13 15:24
When trying to debug braille issues, it would be useful to record what is being sent to the display and what is being displayed.

This would be similar to the information logged in speak() (speech.py:421)

If we also log the braille being displayed on the display using unicode braille, it will allow us
to quickly correct/improve braille tables in the future.

Thanks.

[nvaccessAuto]

Comment 1 by ragb on 2012-02-13 15:49
+1 for this. I have done it locally...

[nvaccessAuto]

Comment 2 by jteh on 2012-02-13 22:13
This definitely needs to be done. However, the question is what to log.

We generate the text for the entire braille buffer (which may span several display widths) and then translate it directly into dots (not computer braille). This makes it unrealistic to retrieve the text or computer braille for just the window being displayed.

So, we can log three things:

1. The untranslated text of the entire buffer;
2. The translated dots for the entire buffer (probably not useful);
3. The translated dots for the window being displayed.
   I think (3) is the most useful in some ways, as it is what the user sees, but dots make quick debugging tricky. (1) doesn't give an accurate idea of what the user is actually seeing and won't allow for debugging of scrolling behaviour.

Thoughts?

[nvaccessAuto]

Comment 3 by ragb (in reply to comment 2) on 2012-02-14 00:46
Replying to jteh:

This definitely needs to be done. However, the question is what to log.

We generate the text for the entire braille buffer (which may span several display widths) and then translate it directly into dots (not computer braille). This makes it unrealistic to retrieve the text or computer braille for just the window being displayed.

So, we can log three things:

1. The untranslated text of the entire buffer;
2. The translated dots for the entire buffer (probably not useful);
3. The translated dots for the window being displayed.

I think (3) is the most useful in some ways, as it is what the user sees, but dots make quick debugging tricky. (1) doesn't give an accurate idea of what the user is actually seeing and won't allow for debugging of scrolling behaviour.

Thoughts?

I've been using something similar to number one since I was only interessted in text that is converted to braille, not in the dots themselvs or braille window. However beeing abble to log "wht the user sees" might be important on some situations (i.g. scrolling and braille table testing). Logging only translated dots window (number 3) makes things difficult for debugging; I think that for a readable log the untranslated buffer must be logged before the translated dots window.

My suggestion is so 1 + 3. If translated and displayed dots make the log file very verbose a custom log level might be considered. The format of translated dots in the log file is also something to have in mind: either hex or dots naming (i.g. 1345 1234 145 1 for NVDA) work for me.

[nvaccessAuto]

Comment 4 by jteh on 2012-02-14 02:16
Both 1) and 3) are now logged in 3a40753. I'm not really willing to implement a custom log level just for this, so if this really is too verbose, we'll have to log the cells at level debug. However, i think it'll be fine.
Changes:
Milestone changed from None to 2012.1
State: closed