テキスト編集で改行を通知
nishimoto nishimoto nvda-japanese-users への投稿：
NVDA 2014.2jpです。 文章作成中、改行のEnterしても無音です。 なんとか改行通知していただけないでしょうか。
前述のご指摘と関連がありそうですが、どういう状況でなにが起きていて、何を期待されているのか、 もうすこし情報が必要です。
nishimoto すこし前のご報告ですが nvda-japanese-users 1222 で下記のご指摘をいただいています：
Windows LiveMailで新規メッセージを作成していて気づきました。 エンターキーを押して改行しても、音声で「改行」と発声しません。 点字も「編集可能ドキュメント」と表示されたまま動きません。 改行されたことを音声で知らせていただきたいです。
追記：同じ内容をさきほど書いたのですが、意図しないリンクが張られてしまったので書き直しました。
nishimoto メーリングリストで紹介した本家の関連チケット
3279 NVDA doesn't say "new line"
nishimoto 「コマンドキーの読み上げ」がチェックなしであっても、エンターキーだけは通知するようにするパッチ案：
メモ帳などで改行をしたときには「エンター」と通知する。
ボタンやメニュー項目をエンターキーで決定したときには「エンター」とは言わないでフォーカスされたオブジェクトを通知する。
エンターキーで日本語入力を確定したときには「エンター、川」のように、確定した文字列の前にエンターと言う。
この仕様でよければテスト版を作ってもいいのですが、日本語入力の確定は区別しないとダメかも知れません。
ちなみにエンターキーを押して改行したかどうか確認するには、書式設定で「行番号の通知」を有効にする方法もあります。
Screen Reader NVDA Japanese
Forkdiff --git a/source/inputCore.py b/source/inputCore.py
index 0bd5ecf..e616be6 100644
--- a/source/inputCore.py
+++ b/source/inputCore.py
@@ -427,6 +427,8 @@ class InputManager(baseObject.AutoPropertyObject):
if config.conf["keyboard"]["speakCommandKeys"] and gesture.shouldReportAsCommand:
queueHandler.queueFunction(queueHandler.eventQueue, speech.speakMessage, gesture.displayName)
+ elif gesture.shouldReportAsEnterKey:
+ queueHandler.queueFunction(queueHandler.eventQueue, speech.speakMessage, gesture.displayName)
gesture.reportExtra()
diff --git a/source/keyboardHandler.py b/source/keyboardHandler.py
index 28f56eb..5c45722 100644
--- a/source/keyboardHandler.py
+++ b/source/keyboardHandler.py
@@ -405,6 +405,9 @@ class KeyboardInputGesture(inputCore.InputGesture):
return True
return False
+ def _get_shouldReportAsEnterKey(self):
+ return self.vkCode == winUser.VK_RETURN
+
def _get_speechEffectWhenExecuted(self):
if inputCore.manager.isInputHelpActive:
return self.SPEECHEFFECT_CANCEL
nishimoto nishimoto 日本語テスト版 jpalpha140701
https://dl.dropboxusercontent.com/u/62564469/nvda_jpalpha140701.exe
ビープ音でのエンターの通知は音量を控えめにしました。
半角全角ビープのオプションは「ビープ音によるコマンドキーの通知」のようにオプションの名前を変えて、機能を一般化してみてはどうかという意図があります。
エンターキーの通知を一切したくないというニーズにはいまのところお応えできていません。
ご意見があればお聞かせください。
To ssh://git@bitbucket.org/nvdajp/nvdajp.git * [new branch] ti33969v2 -> ti33969v2
nishimoto フォーカスが編集可能テキストでないときには「エンター」の通知をしないようにする修正案：
[ti33969v3 ee7a61f] check if current focus is editable text 1 file changed, 7 insertions(+), 5 deletions(-) To ssh://git@bitbucket.org/nvdajp/nvdajp.git * [new branch] ti33969v3 -> ti33969v3
Microsoft IME の候補ウィンドウが開いたあとで押された Enter は通知しませんが、第一候補（候補ウィンドウが開く前）の Enter の通知はこの実装ではまだ回避できません。
また ATOK は候補ウィンドウが開いてもフォーカスが移動しないので、ATOK での変換中も Enter の通知は回避できません。
nishimoto 日本語テスト版 jpalpha140703
https://dl.dropboxusercontent.com/u/62564469/nvda_jpalpha140703.exe
日本語入力の確定の Enter で、ビープの抑止はできませんが、音声の場合は確定した文字列だけを読み上げるようにしてみました。
nishimoto 作業記録：
To ssh://git@bitbucket.org/nvdajp/nvdajp.git 6595c74..eda200d ti33969v3 -> ti33969v3
やむメールでエンターを通知しないという報告があります。
#30938 で「やむメール」を検討したときに .NET フレームワークが使われているという話だったので、 ひきつづき検討します。
nishimoto Visual Studio 2013 で標準的な複数行エディットとリッチテキストエディットを張り付けた Windows Form アプリを作ってみましたが、 ROLE_EDITABLETEXT なのでエンターを通知しています。
XAML アプリ (NvdaDemoApp) も大丈夫そうです。 https://bitbucket.org/nishimotz/nvdademoapp
エンターを通知しないアプリが見つかったときは、ログを取って個別に対応していくことになりそうです。
nishimoto 日本語テスト版 jpalpha140704
https://dl.dropboxusercontent.com/u/62564469/nvda_jpalpha140704.exe
ti33969v3 ブランチの更新（Windows Live Mail への対応）をマージしています。
本来はマルチラインでないエディットコントロールでは改行は入力されないのですが、 マルチラインかどうかの判定はうまくできない場合があります。
エンターキーが押された処理の後で、文字変換の確定の処理を行うため、 とりあえずエンターキーを通知しておいて、後者の場合にはその通知をキャンセルしています。 その結果「エンター」を出力した直後にキャンセルする処理が間に合わず、「エ」の音声が断片的に聞こえてしまうことがあります。 エンターを出力するタイミングを遅らせるのが一つの対策と思います。
これまでも、エンターで確定したときに誤判定で「クリア」を通知することがときどき起きていますが、 今回の実装でときどき起こるようになったは、確定のエンターを押したときに、 誤判定の「クリア」、中途半端にキャンセルされたエンターの「エ」、確定された文字列、 などが立て続けに読み上げられるという現象です。
全体として、安定した動作とは言いがたいので、現状の実装には否定的なご意見もあろうかと思います。
「改行」の通知ではなく「エンター」の通知をしている理由は以下の通りです：
（１） 「コマンドキーの読み上げ」機能と仕様をそろえたい （もし揃えないとしたら、「コマンドキーの読み上げ」が有効の場合には、 エンターと改行の両方が通知されないとおかしいことになる）
（２） キーが押されたことではなく「改行が入力されたこと」を判定する技術的な目途がまだ立っていない
引き続きご議論いただければ幸いです。
nishimoto 日本語テスト版 jpalpha140704v2
https://dl.dropboxusercontent.com/u/62564469/nvda_jpalpha140704v2.exe
ti33969v3 ブランチの更新（下記）をさらにマージ：
nishimoto 点字ディスプレイのタッチカーソルを使うと下記のエラーが出ているというご報告をいただいています：
IO - brailleDisplayDrivers.kgs.nvdaKgsHandleKeyInfoProc (06:41:15): names route 10 IO - inputCore.InputManager.executeGesture (06:41:15): Input: br(kgs):route ERROR - unhandled exception (06:41:15): Traceback (most recent call last): File "_ctypes/callbacks.c", line 314, in 'calling callback function' File "brailleDisplayDrivers\kgs.pyo", line 128, in nvdaKgsHandleKeyInfoProc File "inputCore.pyo", line 431, in executeGesture AttributeError: 'InputGesture' object has no attribute 'shouldReportAsEnterKey'
nishimoto 日本語テスト版 jpalpha140705
https://dl.dropboxusercontent.com/u/62564469/nvda_jpalpha140705.exe
inputCore で AttributeError が出ないようにしたつもりですが、こちらではまだ実機での確認をしていません。
本チケットのゴールは要望にあった
色々と設定など変えてみておりますが、 テキスト入力の際、改行をするためエンターキーを押しますが 復帰や、改行などと音声が出ません。 設定で音声が出るようになるものなのか、それとも現在は設定を変えても出ない のかが分りません。 私は全盲のため、音声やbeep音がするだけでも改行されたことが分かり安心 できます。
を満たす実装になるかと思われます。
おそらく、要望者は PC-Talker を普段お使いで、それに見合った操作性を NVDA に期待しています。
日本語テスト版 jpalpha140705 https://dl.dropboxusercontent.com/u/62564469/nvda_jpalpha140705.exe
上記、現在の実装では、
・必ずしもリターンコードを検出しているわけではないため独自にエディットボックスをコールバックしている ケースでは改行が実際にされていないにも関わらず「エンター」と発生する可能性があること
・リー丼リー属性エディットクラスでの挙動が不確定になる可能性があること
・改行コードが送出されていないにも関わらず「エンター」と読み上げるケースがあること
・エンターそうとうの操作をしたときに、同時に FocusChange イベントが発生したときに 「エンター」という発生が遅延するケースがある （スリープタイマーが影響している）
・また上記と同様の場合で、別イベントハンドラで・スピーチアウトされたときに 別のスピーチが優先されたり、されなかったりして、「エンター」の発声タイミングが確実ではないこと
上記の事項を十分考慮の上、継続して検討していくことが必要です。
nishimoto ti33969v3 をマージしない場合に
に別途対応するかも知れないので、すこし詳細を書いておきます。
現在 NVDAHelper でバックスペースが押されたときの「クリア」の通知に使われている
winUser.getAsyncKeyState(winUser.VK_BACK)&1
は最上位ビットを使えば「現在押されているか」、再開ビットを使えば「前回のコール以降、今回のコールまでに押されたか」を返しますが、 Microsoft Word で新規ドキュメントに日本語を入力してすぐにエンターを押した状況では、 なぜか「バックスペースが過去に押された状況」のフラグが立ったままになっています。 エンターキーで確定したときに「クリア」を通知してしまうのはこれが原因と思われます。 （確認は Windows 8.1 64ビット, Microsoft IME, Word 2013 で行っています）
これはアプリケーションの起動から最初の handleInputCompositionEnd の実行までのあいだに getAsyncKeyState を一度でも実行してやることで 回避できるだろうという判断から、今回のエンターキーの通知判定の直前に、ダミーの VK_BACK 判定を一度行っています。
nishimoto 「テキスト編集でEnterキーを通知」が有効であっても、キーボード設定「入力キーの読み上げ」がチェックなしのときには、テキスト編集の Enter キーをを通知しないほうが自然な気もします。
検討させてください。
nishimoto 日本語テスト版 jpalpha140722
https://dl.dropboxusercontent.com/u/62564469/nvda_jpalpha140722.exe
ti33969v3 ブランチについて：
nishimoto 概要の変更：
変更前：「コマンドキーの読み上げ」がチェックなしでもエンターキーだけ通知する
変更後：テキスト編集で改行を通知
以前よりも、チケットがたてられたときの要望通りの仕様になっているように思われます。
そこで、もう少し、改善を期待したいのですが、
「改行」を創出する方法は、エンターキーだけではない、ことを想定し、 できるだけ文字コードをきちんと判定するようにしていただけませんか。
たとえば、Excelでのセル編集ボックスはF2でオープンします。 このときの「改行」は Alt + Enter です。
アプリケーションによってはエンターキー以外でも改行コードが創出できることもあります。 伝統的には Ctrl + m です。 従って、文字コード判定を実装することが望まれます。
加えて検討課題として、 「改行」と読ませるか「復帰」と読ませるかです。
下記のアルファでは、たとえばメモ帳でエンターキーを押したときには「改行」なのに対して、 左右矢印キーで改行マークにカーソルがフォーカスされた場合には「復帰」です。 ユーザー・エクスペリエンスの観点では、このような不整合に対して、理解を損なう恐れがあります。 ユーザー・アクションに対応する統一的なラベルが期待されます。
nishimoto への返信
日本語テスト版 jpalpha140722 https://dl.dropboxusercontent.com/u/62564469/nvda_jpalpha140722.exe ti33969v3 ブランチについて： * いままでのタイマーで出力キューを制御する実装を廃止して editableText の enter ジェスチャーを使う実装に変更した * エンターキーではなく「改行」を通知するようにした（実際には Enter が押されてキャレットが移動したことを判定している） * キーボード設定「入力キーの読み上げ」がチェックなしのときには通知しないようにした
nishimoto jpbeta ブランチに ti33969v3 をマージしました。
To ssh://git@bitbucket.org/nvdajp/nvdajp.git fa09c78..66badf3 jpbeta -> jpbeta
マージする前に config の変数名を変更しました：
[language] jpAnnounceNewLine = True
またデフォルト値を false にして、日本語設定「テキスト編集で改行を通知」は初期状態では無効にしました。
「NVDA日本語版の説明」には下記のように記述し、動作が不完全な可能性があることをユーザーに伝えることにしました。
+++ テキスト編集で改行を通知 +++ この設定を有効にすると、テキスト編集中にエンターキーが押されたときに「改行」を通知します。 ただし日本語入力の確定操作でエンターキーが押されたときには通知しません。 キーボード設定「入力キーの読み上げ」がチェックなしの場合にもこの通知は行いません。 この機能はアプリケーションによっては正しく動作しない場合があります。
このチケットはクローズして、新しいチケットで関連する課題を検討したいと思います。
nvdajp 宛にいただいたメールを共有します。
個別にお返事をするかどうかはまだ決めていません。