Ticket #33969

テキスト編集で改行を通知

Open Date: 2014-06-24 08:58 Last Update: 2014-07-30 11:25

Reporter: nishimoto Owner: (None)
Type: Feature Requests Status: Closed
Component: IME MileStone: 2014.3jp-public-beta (closed)
Priority: 5 - Medium Severity: 5 - Medium
Resolution: Fixed

Details

nvdajp 宛にいただいたメールを共有します。

個別にお返事をするかどうかはまだ決めていません。

NVDA開発チーム 御中

最近、NVDAの勉強を始めました。

色々と設定など変えてみておりますが、
テキスト入力の際、改行をするためエンターキーを押しますが
復帰や、改行などと音声が出ません。
設定で音声が出るようになるものなのか、それとも現在は設定を変えても出ない
のかが分りません。
私は全盲のため、音声やbeep音がするだけでも改行されたことが分かり安心
できます。

ご多忙とは存じますが、ぜひご教授いただけましたら幸いです。

Attachment File List

No attachments

Ticket History (3/23 Histories)

2014-06-24 08:58 Updated by: nishimoto
  • New Ticket "改行時の読みについて" created
2014-06-26 08:16 Updated by: nishimoto
Comment

nvda-japanese-users への投稿:

NVDA 2014.2jpです。
文章作成中、改行のEnterしても無音です。
なんとか改行通知していただけないでしょうか。

前述のご指摘と関連がありそうですが、どういう状況でなにが起きていて、何を期待されているのか、 もうすこし情報が必要です。

2014-06-26 12:32 Updated by: nishimoto
Comment

すこし前のご報告ですが nvda-japanese-users 1222 で下記のご指摘をいただいています:

Windows LiveMailで新規メッセージを作成していて気づきました。

エンターキーを押して改行しても、音声で「改行」と発声しません。
点字も「編集可能ドキュメント」と表示されたまま動きません。

改行されたことを音声で知らせていただきたいです。

追記:同じ内容をさきほど書いたのですが、意図しないリンクが張られてしまったので書き直しました。

2014-06-26 19:14 Updated by: nishimoto
Comment

メーリングリストで紹介した本家の関連チケット

3279 NVDA doesn't say "new line"

http://community.nvda-project.org/ticket/3279

2014-06-30 22:41 Updated by: nishimoto
Comment

「コマンドキーの読み上げ」がチェックなしであっても、エンターキーだけは通知するようにするパッチ案:

メモ帳などで改行をしたときには「エンター」と通知する。

ボタンやメニュー項目をエンターキーで決定したときには「エンター」とは言わないでフォーカスされたオブジェクトを通知する。

エンターキーで日本語入力を確定したときには「エンター、川」のように、確定した文字列の前にエンターと言う。

この仕様でよければテスト版を作ってもいいのですが、日本語入力の確定は区別しないとダメかも知れません。

ちなみにエンターキーを押して改行したかどうか確認するには、書式設定で「行番号の通知」を有効にする方法もあります。

diff --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
2014-07-01 08:25 Updated by: nishimoto
  • Milestone Update from (None) to 2014.3jp-public-beta (closed)
  • Resolution Update from None to Accepted
  • Type Update from Support Request to Feature Requests
  • Summary Updated
2014-07-01 12:03 Updated by: nishimoto
Comment

日本語テスト版 jpalpha140701

https://dl.dropboxusercontent.com/u/62564469/nvda_jpalpha140701.exe

  • コマンドキーの読み上げがチェックあり:いままでと同じ動作
  • コマンドキーの読み上げがチェックなしで、日本語設定「半角全角キーが押されたらビープ音を鳴らす」がチェックあり:半角全角キーに加えて、エンターキーもビープ音で通知する
  • コマンドキーの読み上げも、半角全角ビープ音もチェックなし:エンターキーだけ音声で通知

ビープ音でのエンターの通知は音量を控えめにしました。

半角全角ビープのオプションは「ビープ音によるコマンドキーの通知」のようにオプションの名前を変えて、機能を一般化してみてはどうかという意図があります。

エンターキーの通知を一切したくないというニーズにはいまのところお応えできていません。

ご意見があればお聞かせください。

To ssh://git@bitbucket.org/nvdajp/nvdajp.git
 * [new branch]      ti33969v2 -> ti33969v2
2014-07-03 00:02 Updated by: nishimoto
Comment

フォーカスが編集可能テキストでないときには「エンター」の通知をしないようにする修正案:

[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 の通知は回避できません。

2014-07-03 11:52 Updated by: nishimoto
Comment

日本語テスト版 jpalpha140703

https://dl.dropboxusercontent.com/u/62564469/nvda_jpalpha140703.exe

日本語入力の確定の Enter で、ビープの抑止はできませんが、音声の場合は確定した文字列だけを読み上げるようにしてみました。

2014-07-03 22:21 Updated by: nishimoto
Comment

作業記録:

  • ワードパッド、Thunderbird でエンターを通知する
  • Excel でエンターを押したときにエラーが出ないようにする
To ssh://git@bitbucket.org/nvdajp/nvdajp.git
   6595c74..eda200d  ti33969v3 -> ti33969v3

やむメールでエンターを通知しないという報告があります。

#30938 で「やむメール」を検討したときに .NET フレームワークが使われているという話だったので、 ひきつづき検討します。

2014-07-03 22:48 Updated by: nishimoto
Comment

Visual Studio 2013 で標準的な複数行エディットとリッチテキストエディットを張り付けた Windows Form アプリを作ってみましたが、 ROLE_EDITABLETEXT なのでエンターを通知しています。

XAML アプリ (NvdaDemoApp) も大丈夫そうです。 https://bitbucket.org/nishimotz/nvdademoapp

エンターを通知しないアプリが見つかったときは、ログを取って個別に対応していくことになりそうです。

2014-07-04 10:55 Updated by: nishimoto
Comment

日本語テスト版 jpalpha140704

https://dl.dropboxusercontent.com/u/62564469/nvda_jpalpha140704.exe

ti33969v3 ブランチの更新(Windows Live Mail への対応)をマージしています。

本来はマルチラインでないエディットコントロールでは改行は入力されないのですが、 マルチラインかどうかの判定はうまくできない場合があります。

エンターキーが押された処理の後で、文字変換の確定の処理を行うため、 とりあえずエンターキーを通知しておいて、後者の場合にはその通知をキャンセルしています。 その結果「エンター」を出力した直後にキャンセルする処理が間に合わず、「エ」の音声が断片的に聞こえてしまうことがあります。 エンターを出力するタイミングを遅らせるのが一つの対策と思います。

これまでも、エンターで確定したときに誤判定で「クリア」を通知することがときどき起きていますが、 今回の実装でときどき起こるようになったは、確定のエンターを押したときに、 誤判定の「クリア」、中途半端にキャンセルされたエンターの「エ」、確定された文字列、 などが立て続けに読み上げられるという現象です。

全体として、安定した動作とは言いがたいので、現状の実装には否定的なご意見もあろうかと思います。

「改行」の通知ではなく「エンター」の通知をしている理由は以下の通りです:

(1) 「コマンドキーの読み上げ」機能と仕様をそろえたい (もし揃えないとしたら、「コマンドキーの読み上げ」が有効の場合には、 エンターと改行の両方が通知されないとおかしいことになる)

(2) キーが押されたことではなく「改行が入力されたこと」を判定する技術的な目途がまだ立っていない

引き続きご議論いただければ幸いです。

2014-07-04 14:41 Updated by: nishimoto
Comment

日本語テスト版 jpalpha140704v2

https://dl.dropboxusercontent.com/u/62564469/nvda_jpalpha140704v2.exe

ti33969v3 ブランチの更新(下記)をさらにマージ:

  • 日本語設定「テキスト編集でEnterキーを通知」オプションを追加して、機能を無効にできるようにした
  • ビープ音で通知する機能を廃止した
  • エンターの通知を 100msec 遅くして、文字変換確定での動作を改善した(まだ不安定な状況はありそう)
  • Microsoft Word で新規ドキュメントに日本語を入力してすぐにエンターを押すと確定と同時に「クリア」と通知される問題を回避する修正
2014-07-05 09:07 Updated by: nishimoto
Comment

点字ディスプレイのタッチカーソルを使うと下記のエラーが出ているというご報告をいただいています:

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'
2014-07-05 09:35 Updated by: nishimoto
Comment

日本語テスト版 jpalpha140705

https://dl.dropboxusercontent.com/u/62564469/nvda_jpalpha140705.exe

inputCore で AttributeError が出ないようにしたつもりですが、こちらではまだ実機での確認をしていません。

2014-07-05 10:06 Updated by: misono
Comment

本チケットのゴールは要望にあった

色々と設定など変えてみておりますが、
テキスト入力の際、改行をするためエンターキーを押しますが
復帰や、改行などと音声が出ません。
設定で音声が出るようになるものなのか、それとも現在は設定を変えても出ない
のかが分りません。
私は全盲のため、音声やbeep音がするだけでも改行されたことが分かり安心
できます。

を満たす実装になるかと思われます。

おそらく、要望者は PC-Talker を普段お使いで、それに見合った操作性を NVDA に期待しています。

日本語テスト版 jpalpha140705 https://dl.dropboxusercontent.com/u/62564469/nvda_jpalpha140705.exe

上記、現在の実装では、

・必ずしもリターンコードを検出しているわけではないため独自にエディットボックスをコールバックしている ケースでは改行が実際にされていないにも関わらず「エンター」と発生する可能性があること

・リー丼リー属性エディットクラスでの挙動が不確定になる可能性があること

・改行コードが送出されていないにも関わらず「エンター」と読み上げるケースがあること

・エンターそうとうの操作をしたときに、同時に FocusChange イベントが発生したときに 「エンター」という発生が遅延するケースがある (スリープタイマーが影響している)

・また上記と同様の場合で、別イベントハンドラで・スピーチアウトされたときに 別のスピーチが優先されたり、されなかったりして、「エンター」の発声タイミングが確実ではないこと

上記の事項を十分考慮の上、継続して検討していくことが必要です。

2014-07-05 11:30 Updated by: nishimoto
Comment

ti33969v3 をマージしない場合に

  • Microsoft Word で新規ドキュメントに日本語を入力してすぐにエンターを押すと確定と同時に「クリア」と通知される問題

に別途対応するかも知れないので、すこし詳細を書いておきます。

現在 NVDAHelper でバックスペースが押されたときの「クリア」の通知に使われている

winUser.getAsyncKeyState(winUser.VK_BACK)&1

は最上位ビットを使えば「現在押されているか」、再開ビットを使えば「前回のコール以降、今回のコールまでに押されたか」を返しますが、 Microsoft Word で新規ドキュメントに日本語を入力してすぐにエンターを押した状況では、 なぜか「バックスペースが過去に押された状況」のフラグが立ったままになっています。 エンターキーで確定したときに「クリア」を通知してしまうのはこれが原因と思われます。 (確認は Windows 8.1 64ビット, Microsoft IME, Word 2013 で行っています)

これはアプリケーションの起動から最初の handleInputCompositionEnd の実行までのあいだに getAsyncKeyState を一度でも実行してやることで 回避できるだろうという判断から、今回のエンターキーの通知判定の直前に、ダミーの VK_BACK 判定を一度行っています。

2014-07-17 12:28 Updated by: nishimoto
Comment

「テキスト編集でEnterキーを通知」が有効であっても、キーボード設定「入力キーの読み上げ」がチェックなしのときには、テキスト編集の Enter キーをを通知しないほうが自然な気もします。

検討させてください。

2014-07-21 23:53 Updated by: nishimoto
Comment

日本語テスト版 jpalpha140722

https://dl.dropboxusercontent.com/u/62564469/nvda_jpalpha140722.exe

ti33969v3 ブランチについて:

  • いままでのタイマーで出力キューを制御する実装を廃止して editableText の enter ジェスチャーを使う実装に変更した
  • エンターキーではなく「改行」を通知するようにした(実際には Enter が押されてキャレットが移動したことを判定している)
  • キーボード設定「入力キーの読み上げ」がチェックなしのときには通知しないようにした
2014-07-22 09:34 Updated by: nishimoto
  • Summary Updated
Comment

概要の変更:

変更前:「コマンドキーの読み上げ」がチェックなしでもエンターキーだけ通知する

変更後:テキスト編集で改行を通知

2014-07-23 12:49 Updated by: misono
Comment

以前よりも、チケットがたてられたときの要望通りの仕様になっているように思われます。

そこで、もう少し、改善を期待したいのですが、

「改行」を創出する方法は、エンターキーだけではない、ことを想定し、 できるだけ文字コードをきちんと判定するようにしていただけませんか。

たとえば、Excelでのセル編集ボックスはF2でオープンします。 このときの「改行」は Alt + Enter です。

アプリケーションによってはエンターキー以外でも改行コードが創出できることもあります。 伝統的には Ctrl + m です。 従って、文字コード判定を実装することが望まれます。

加えて検討課題として、 「改行」と読ませるか「復帰」と読ませるかです。

下記のアルファでは、たとえばメモ帳でエンターキーを押したときには「改行」なのに対して、 左右矢印キーで改行マークにカーソルがフォーカスされた場合には「復帰」です。 ユーザー・エクスペリエンスの観点では、このような不整合に対して、理解を損なう恐れがあります。 ユーザー・アクションに対応する統一的なラベルが期待されます。

nishimoto への返信

日本語テスト版 jpalpha140722 https://dl.dropboxusercontent.com/u/62564469/nvda_jpalpha140722.exe ti33969v3 ブランチについて: * いままでのタイマーで出力キューを制御する実装を廃止して editableText の enter ジェスチャーを使う実装に変更した * エンターキーではなく「改行」を通知するようにした(実際には Enter が押されてキャレットが移動したことを判定している) * キーボード設定「入力キーの読み上げ」がチェックなしのときには通知しないようにした

2014-07-27 08:24 Updated by: misono
Comment
(This comment has been deleted)
2014-07-30 11:25 Updated by: nishimoto
  • Ticket Close date is changed to 2014-07-30 11:25
  • Status Update from Open to Closed
  • Resolution Update from Accepted to Fixed
  • Component Update from (None) to IME
Comment

jpbeta ブランチに ti33969v3 をマージしました。

To ssh://git@bitbucket.org/nvdajp/nvdajp.git
   fa09c78..66badf3  jpbeta -> jpbeta

マージする前に config の変数名を変更しました:

[language]
	jpAnnounceNewLine = True

またデフォルト値を false にして、日本語設定「テキスト編集で改行を通知」は初期状態では無効にしました。

「NVDA日本語版の説明」には下記のように記述し、動作が不完全な可能性があることをユーザーに伝えることにしました。

+++ テキスト編集で改行を通知 +++

この設定を有効にすると、テキスト編集中にエンターキーが押されたときに「改行」を通知します。
ただし日本語入力の確定操作でエンターキーが押されたときには通知しません。
キーボード設定「入力キーの読み上げ」がチェックなしの場合にもこの通知は行いません。
この機能はアプリケーションによっては正しく動作しない場合があります。

このチケットはクローズして、新しいチケットで関連する課題を検討したいと思います。

Edit

Please login to add comment to this ticket » Login