Hatena::ブログ(Diary)

applet@Hatena このページをアンテナに追加 RSSフィード

2012-03-12

キーボードのUnit IDについて

のどかでは、キーボードのUnit IDを、モディファイヤー K0-, K1-, K2-, K3-で識別可能なよう拡張してある。しかしながらキーボードの認識は動的なので、設定ファイルで区別するよう記述しても、動的に入れ替わるという問題があった。

チケットとしてはこちら。

http://sourceforge.jp/ticket/browse.php?group_id=3682&tid=26958

少し調査した結果、下記レジストリエントリに現在のUnit ID 0~3に割り当てられたキーボードハードウェアIDの一覧が存在する。

HKLM\SYSTEM\CurrentControlSet\services\kbdclass\Enum

例えばワイヤレスキーボードのアダプタを外してから、レジストリの表示を更新すると、反映されていることが判る。

ハードウェアIDはデバイスマネージャー上のキーボードデバイスプロパティで確認可能である。

実際にのどかで、上記レジストリの情報をいったん覚えておいて、起動時に再度確認して、入れ替わっていたら、動的ににUnit IDを読み換えるといった実現手段が考えられる。キーボードが無くなっていたり、知らない新しいキーボードが来た時にどうするかといった例外処理を考える必要があり、それがいい加減だと確実に読み換えるのは難しそうなので、より良い実現手段を考える必要があるだろう。

その他、別件だがキーボードごとに異なるレイアウト(US/JP)にする手法を解説しているページ(下記URL)を見つけたが、infファイルを書き換えてしまうので署名なしドライバになる様子。

http://neet.waterblue.net/2010/10/13/windows7%E3%81%A7%E3%81%AE%E3%82%AD%E3%83%BC%E3%83%9C%E3%83%BC%E3%83%89%E3%83%AC%E3%82%A4%E3%82%A2%E3%82%A6%E3%83%88%E3%81%AE%E6%8C%87%E5%AE%9A/

infを直さずに、レジストリだけで対応する例は下記。

http://gajumaru.ddo.jp/wordpress/?p=144

http://blog.heiichi.com/?eid=792239

http://tnfront.net/?p=255

上記を簡単にできるようにすべきだが、いずれにせよ、UnitIDは入れ替わることがあるので、K0-固定化対応自体は必要。

2012-01-06

Metro対応が必要(いや不要?)

スラッシュドットの記事によれば http://goo.gl/JMGMj

Windows 8には、リセットやリフレッシュと言うOS初期化機能が付く様子。

特にリフレッシュの方は、Metro対応アプリならばインストールされたままとなるようなので、「のどか」もMetro対応した方が良いことになる。

OS初期化の際のソフトの再インストールは一つ二つならともかく、たくさんあると大変だし、パワーユーザ向けに専用のイメージも作れるようだが、簡単な方の選択肢は用意した方が良いだろうと思う。

来月あたり出てくるらしいWindows 8 β版で状況が少しはっきりすることだろう。

追記 2012-01-10

Metro対応すると、Windowsストアでの流通となるはずだが、WinRTしか使えないアプリなので、UIだけMetro対応しておいて、従来のWin32 APIを使う部位やデバイスドライバを同梱しておいても良いのなら問題無いが、それが出来ないのならば、「のどか」のようなシステム側ユーティリテイでは、Metro対応する必然性が何もない。従って、どのような状況になるのか注意して見ていくことがあるだろう。

2011-12-22

4.20は何を目指すか

4.19aをリリースできたので、もう年内はリリースしないものの、次の4.20では、何を目指すか考える必要がある。

ひとつは、積み残した TSF対応。すなわちIME2010/Offce2010の組み合わせでIC-などがきちんと取れない件の改修であろう。

あとは、可能性を探る必要があるが、K0-, K1-などの固定化。

それから、Sound Volume PluginのアプリケーションごとのVolume制御。

今後の課題としては、Windows 8に向けての修正や、やはりGUI Editであろう。

上記の3個の中で、まずどれを進めるかと言えば、改修依頼が出ているTSF対応であろうと思う。

2011-12-20

「のどか」4.19aリリース

2011/12/20 「のどか」4.19aをリリース

以下、変更内容。

修正

4.19で発生した不具合を修正いたしました。

リリース案内等、煩雑なこととなったことをお詫びするとともに、不具合報告頂いた方々大変ありがとうございました。

なお、DLL側の問題であったために、実行ファイルのバージョン番号は4.19のままとなります。

2011/12/18 4.19 リリース取りやめ

起動時に、Windowごとのキー入れ替えに失敗していたため、リリースを取りやめました。

2011-12-17 「のどか」4.19をリリース

修正

・設定ウィンドウの最前面表示

  設定ウィンドウが既に表示されていた時に、通知領域の「のどか」アイコンからの設定を選んだ場合や、ログウィンドウから設定ボタンを押した場合に最前面に表示されるようにしました。

マウスフック有効時に他のアプリのスクロールなどが遅延する不具合対応

  マウスキーボードLL Hookからの入力処理をウィンドウメッセージからキュー変数に直接代入するように変更して(yamyと同じ)、負荷を低減することで対応いたしました。

・不定期にキーリピートする不具合対応

  必ず起きる環境では本不具合が発生しており、キー入力時の余分なモディファイヤーキー等ロック通知処理(notifyLockState())を削って、キーリピートしやすい不具合発生頻度を下げました。なお、まだ発生する環境では発生します。

・のどか終了時に、他のアプリアプリケーションエラーを起こす問題対応

  sirius内部のフック処理ルーチンにおいて、フック解除実行時にフックルーチンに入ってしまった場合、抜けるよう修正いたしました。

  また、sirius内部の共有メモリ解除(SiriusReleaseHook())時にに 解放処理(UnmapViewOfFile(pCv))を追加しました。

変更

・設定ファイルのシンボリックリンク対応

  設定ファイルがシンボリックリンクファイルであった場合、実体のファイルサイズが0で無ければロードされるようにしました。

追加

・起動時引数 -L, -lの追加

  -L :「のどか」起動時に、詳細をチェックした状態でログウィンドウを開きます。

  -l :「のどか」起動時に、ログウィンドウを開きます。

  どちらも既にログウィンドウが表示されている場合には、最前面にするのみです。-Lでは詳細チェックは実行されません。

TSFに対応しているMS-IME 2010やATOK 2011と、Microsoft Office系アプリとの組み合わせにおいて、モディファイヤーが正確に取得できない不具合について、バグとして記載しました。

 以上、よろしくお願いいたします。

2011-12-18

「のどか」4.19リリースの取りやめました。

大変お世話になっています。下記のように4.19のリリースを行いましたが

ウィンドウごとのキー入れ替えができないという不具合報告を頂いたので

4.19のリリースは取りやめました。

ダウンロードされた方々、大変申し訳ありませんでした。

なお不具合が報告されたサンプル版は、下記となります。

http://www.appletkan.com/download/nodoka-4.19_sample_setup_2011-12-17.zip

---

「のどか」の新しいバージョンをリリースします。

 御要望頂いていた いくつかの不具合の修正を行いました。

 試用版はこちら。

 http://www.appletkan.com/download/nodoka-4.19_sample_setup.zip

 なお、修正内容は下記となります。

2011-12-17 「のどか」4.19をリリース

 修正

 ・設定ウィンドウの最前面表示

  設定ウィンドウが既に表示されていた時に、通知領域の「のどか」アイコンからの設定を選んだ場合や、ログウィンドウから設定ボタンを押した場合に最前面に表示されるようにしました。

 ・マウスフック有効時に他のアプリのスクロールなどが遅延する不具合対応

  マウスキーボードLL Hookからの入力処理をウィンドウメッセージからキュー変数に直接代入するように変更して(yamyと同じ)、負荷を低減することで対応いたしました。

 ・不定期にキーリピートする不具合対応

  必ず起きる環境では本不具合が発生しており、キー入力時の余分なモディファイヤーキー等ロック通知処理(notifyLockState())を削って、キーリピートしやすい不具合発生頻度を下げました。なお、まだ発生する環境では発生します。

 ・のどか終了時に、他のアプリアプリケーションエラーを起こす問題対応

  sirius内部のフック処理ルーチンにおいて、フック解除実行時にフックルーチンに入ってしまった場合、抜けるよう修正いたしました。

  また、sirius内部の共有メモリ解除(SiriusReleaseHook())時にに 解放処理(UnmapViewOfFile(pCv))を追加しました。

 変更

 ・設定ファイルのシンボリックリンク対応

  設定ファイルがシンボリックリンクファイルであった場合、実体のファイルサイズが0で無ければロードされるようにしました。

 追加

 ・起動時引数 -L, -lの追加

  -L :「のどか」起動時に、詳細をチェックした状態でログウィンドウを開きます。

  -l :「のどか」起動時に、ログウィンドウを開きます。

  どちらも既にログウィンドウが表示されている場合には、最前面にするのみです。-Lでは詳細チェックは実行されません。

 ・TSFに対応しているMS-IME 2010やATOK 2011と、Microsoft Office系アプリとの組み合わせにおいて、モディファイヤーが正確に取得できない不具合について、バグとして記載しました。

 以上、よろしくお願いいたします。

2011-11-14

Windows 8 Developer Preview上で動かす。

やっと環境を入手したので、64bit版のWindows 8 Developer Preview にのどかをインストールしてみた。

1. setupには、署名がついているにもかかわらず、実行を選択しないとインストールが始まらない。そういうもののようだ。

2.英語環境なので、setup menuなどすべて英語で正しく動いているが、注意書きは日本語で表示されているので、これは正しいのか確認が必要。

3. インストールは問題なく実行され、regeditにて、デバイスドライバがきちんと登録されていることを確認。

4. 再起動後、のどかのアイコンが、Metro上に登録されるが、そういうアプリでは無いので、設定画面が開くようにするとか工夫が必要。またアイコンの大きなものを準備する必要があるだろう。

6. Metro上の のどかアイコンから、フォルダを開いたところ、start menuに登録されているが、startupには登録されていない。しかし自動起動した様子。タスクマネージャスタートアップには登録されているので、そういうもののようだ。

7. メモ帳を起動して、キー入力を確認。キーバインド変更機能は動いているように見える。

のどかは、Windowsの新しいバージョンに対応するときには、メジャーバージョンアップとなるので、課金を予定しているが、このままではお金が取れるような代物では無いので、よくよく考える必要があるだろう。Windows 8リリースまで、1年を切っていると思うが、それだけあれば、GUI編集できるようになるだろうか。

TSFの状態を取り出す。

MS-IME2010あるいはATOK2011を Microsoft Word 2010で使っているときに、かな漢字変換が開始された終了したという窓使いの憂鬱で言うところの IC-が取れなくなっているという不具合のサポートの続き。

本件は、WM_IME_STARTCOMPOSITION, WM_IME_ENDCOMPOSITIONメッセージが飛んでこなくなっているので、窓使いの憂鬱やyamyでも共通の問題ではある。


AutoHotkey IME.ahk によれば、現在開いている変換ウィンドウあるいは候補ウィンドウをclass名で検索して、そのウィンドウを生成したスレッドIDと、変換コンテキストスレッドIDが一致したら、そのウィンドウが開いていると認識するというやり方を実施している。

しかし、これはメモ帳などでは問題がないが、Wordとの組み合わせでは、取れなくなってしまう。そもそもメモ帳では、MS-IME2010, ATOK2011のいずれも、WM_IME_STARTCOMPOSITION, WM_IME_ENDCOMPOSITIONメッセージは飛んでくるので、窓使いの憂鬱の hook.cppでの実装のままで問題は無い。

TSFに対応している sirius_hook_x64.dllでは、Window Messageを送ると実装されている機能を使って変換文字列を取得することが可能である。

それを使って取得した文字列のサイズが0以外なら、ウィンドウが開いていると判断させてみた。

参考ソースとしては下記のような感じ。

SendMessage(pCv->m_hWndFocus, pCv->m_wm_sirius_controll, e_getImeString, NULL);

size_t tmpSize = 0;
tmpSize = wcslen(pCv->m_strImeBuffer);

if(tmpSize > 0)
	dwLock |= 0x20;
else
	dwLock &= 0xdf;

これをのどかに実装すると、メモ帳WORDでは、いずれもIC-は、取れることは取れるが、取れたり取れなかったりで、少しも安定して動作しない。

以上のような状況で、本件は、まだ改修できていない。

sirius_hook内コードを、もっと理解して、直接状態を取得するようにしないとダメだろうと考える。

- 2011-11-16 追記。

sirius_hook.cpp解析中。課題を2点発見する。

1. 共有メモリを使っているが、解放するUnmapViewOfFile()が見当たらないので実装が必要だろう。

2. hookが二つ存在するが、hook解除した際でも、hookルーチンに飛び込むと処理が走る恐れがあるので、抜けるコードが必要である。

 特に、SetTimerがhookの中で起動されるので、これは入れる必要がある。なぜならば、終了したあとで、hookに飛び込んだらTimerが起動してしまうから。

 これが、のどか終了後も、sirius_hookのTimerが残っているという不具合の原因かも知れない。

そのほかに、sirius_hook.cppの元サンプルと思われるReadComp.exeの方もチェックしてみた。

http://go.microsoft.com/fwlink/?LinkId=208731

このコードは、x64で Buildした場合、メモ帳でもWORDでも、TSFとIMMの両方で、変換ウィンドウに表示されている変換文字列を取得し表示可能であるが、この表示ウィンドウが開いているタイミングが、のどかや窓使いの憂鬱でいうところの、IC-状態であるため、この仕掛けを使えば、TSF対応できそうである。

sirius_hook.cppには実装されていないが、このコードでは以前に取得した文字列と新しく取得した文字列が変わっていたら、ウィンドウ表示するので、文字列のサイズで判断するという考え方は、一つの方法であったようだ。

なお、sirius_hookとReadCompでは、大きくコードが異なるので、実現部位のさらなる理解が必要である。

なお、ReadCompは、http://ja.nishimotz.com/text_services_framework

で解説されているので、参考になるだろう。

2011-11-05

音量制御とmayuの改良版

Viata以降のアプリケーションごとの音量制御を「のどか」から制御できた方が良いだろうと思い、いろいろ音量制御のアプリを調べてみるが、以外と存在しないことに気がつく。Vista対応というものは2008年に、sound_volumeプラグインを改良しマスターボリュームだけに対応したものを作った経緯はあるが、それ以降捨て置いていた。

それはさておき、sound_volumeプラグインオリジナル開発元のサイトにたどり着き、&PlugIn関数の改善を施した窓使いの憂鬱ソースが存在することを発見する。

メモリリークを改善したとあるので、不具合改修部位は、いずれ「のどか」に取り込もうと思う。

http://www.ric.hi-ho.ne.jp/giraffe/mayus/

2011-11-02

Microsoft OfficeとMS-IME2010の組み合わせでIC-が取れない問題

不具合報告があり、押しっぱなしになりやすい件、マウスフックがおかしくなる件などは手元では修正できており、評価版は公式掲示板にて公開中。

あと一つ直したいのは、表題のOfficeとIME2010の組み合わせで、IME変換中状態が取れないというもの。

Spy++で見る限り、WM_IME_STARTCOMPOSITIONなどが来なくなっている。

だから、サポートしないというのも解の一つだが、それでは誰も幸せじゃないので、いろいろ検討中。

OfficeTSF対応しているからだと思う。メモ帳などでは問題無いが、OfficeアプリだとIME2010が動きを変えている感じ。

sirius_hook_x64.dllでは、start/end compositionはサポートしていないので、自力で他の方式で検出する必要がある。まだ解決していない。

2011-08-26

dvorak109.nodoka

以前の窓使いの憂鬱から同梱されているdvorak109.mayu

新たにバージョンアップされたものを作者の方から、昨日ご提供頂きました。

http://jbbs.livedoor.jp/bbs/read.cgi/computer/41517/1221286617/376

次回のリリースにて、この新しいバージョンのdvorak109.nodokaを同梱する予定です。

引き継いで早3年となりますが、このようなお申し出があったのは、初めてことであり、感激も ひとしおです。

大変ありがとうございます。


追伸

今は裏でGUI対応を検討しております。いつごろお披露目できるかは、まだ分かりませんが、実験中であり、以前に比べれば少し見通しが立っています。

C#版のGuiEditは起動時間が待てないので破棄し、C++とATL,WTLで書き直す予定です。

2011-08-09

プラグインのx64対応 window-select

昨日、久しぶりに「のどか」の新しいバージョンをリリースできたので、御要望頂いていたプラグインx64対応に着手した。

とりあえず、window-select。

http://www.tamanegi.org/prog/mayu-plugins/#window-select

で配付されているものであり、Visual Studio 2008にて x64版のバイナリは出来たが、なぜかアプリケーションのクラッシュを引き起こす。

いろいろ調べてみて、

http://www.tamanegi.org/prog/src-guide/ や

http://japan.internet.com/developer/20050830/26.html#section_3_2

に書かれているように、他のプロセスからリモートで SetForegroundWindow()を実行させるという機構を使っていて、x64環境ではメモリリークを起こしてしまう。


CreateRemoteThread()で、x64バイナリから、x86バイナリへのインジェクションは可能なようだが

http://ja.w3support.net/index.php?db=so&id=494284

そこまで頑張る必然性は何もないので、「のどか」でのワークアラウンド setForegroundWindow()のルーチンを持って来て代用させる。

とりあえず落ちなくなったようなので、様子を見てリリースの方向。

---

2011-08-10 追記。リリースした。

2011-08-08

「のどか」4.18 リリースのお知らせ

「のどか」の新しいバージョンをリリースいたします。

 IE8,9向けの修正と、リモートデスクトップ向けに展開したままで使えるよう細かな調整などが修正内容となります。

 試用版はこちら。

 http://www.appletkan.com/download/nodoka-4.18_sample_setup.zip


 なお、修正内容は下記となります。

2011-08-08 「のどか」4.18をリリース

 修正

 ・4.13以降、IE8,IE9プロセスが低整合性レベルで動いている場合、共有メモリへのオープンが失敗しウィンドウの調査ができなくなっていたので修正。

 ・Touchpad用のsts4nodokaにおいて、押しっ放しになることがあったので、軽減させた。

 変更

 ・リモートデスクトップ上で動作していることを検出した場合、エラー表示していたが、強制的に、LL Hookモードで動作させるようにした。

 ・docフォルダにhelpが無い場合、実行ファイルと同じフォルダを参照するようにした。

 ・インストールせずに動作させた場合、レジストリにlayoutを示すエントリが存在しないが、その場合英語キーボードと判断し -DUSE104が付いていたが、付けないようにした。

 追加

 ・def option UseTSF, &UseTSF()を用意し、TSFを使わない設定を可能とした。

 以上、よろしくお願いいたします。

2011-07-03

x86とx64のプログラムでキーバインドを変更する。

64bitのWindowsでは、64bitプログラムならc:\Program Filesフォルダにプログラムインストールされるが、32bitプログラムでは、c:\Program Files (x86)フォルダにインストールされるので、その違いを検出して、キーバインドを変更する。

以下の例では、wordpad.exe上で、Ctrl-Aを押したときに、どちらのプログラムかを判断させる。

# wordpad.exex86, x64キーバインドを変える。

include "109.nodoka"			# 109 キーボード設定

keymap Global

# wordpad.exe以外では、non と表示させる。

key C-A = N O N


# x86側のwordpad.exeでは、86 と表示させる。

window WORDPADx86 (/x86/ && /wordpad\.exe/) : Global
key C-A = _8 _6


# x64側のwordpad.exeでは、64 と表示させる。

window WORDPADx64 ( /Program Files\\\\Windows NT/ && /wordpad\.exe/ ): Global
key C-A = _6 _4

2011-05-07

IE8保護モード対応とTSF

デバッグ作業中。

http://sourceforge.jp/ticket/browse.php?group_id=3682&tid=24510

既にIE9が出ているので、IE9上で試している。

YAMYのMailslotを導入し、IE9で表示しているEdit Box内でのIMEの状態はとれるようになってきたが

x64,x86,通常権限,管理者権限の別において、少しずつ挙動が異なる。

残念ながら、TSFを使わない方が、IE9上では安定してステータスを取れるので

def option UseTSF = false を追加。

他の普通のアプリでは問題無いのだが、いろいろ難しい。

Windowごとのオプションにできた方が良いだろうから、ファンクションでも準備しようと思う。

---

4.18リリースでは、Mailslotの導入は未実施。従来のままで修正が確認できたため。2011-08-09追記。

2011-02-15

「のどか」4.17 リリースのお知らせ

 「のどか」の新しいバージョンをリリースいたします。

 細かなバグフィックスと、モディファイヤーキー押しっ放し検出機能追加などが

  修正内容となります。

 試用版はこちら。

 http://www.appletkan.com/download/nodoka-4.17_sample_setup.zip

 なお、修正内容は下記となります。

2011-02-15 「のどか」4.17をリリース

- 修正

 .NET Framework 4が未インストールの場合、インストール時、高速起動化と

 設定ダイアログを開いた際のGuiEditボタンを非活性とした。 

 その結果、.NET Framework 4がインストールされていない環境で、インストール時に

 エラーが発生しないようにした。

- 変更

 GuiEdit高速起動のための dotnet_starter.exeの復活

 GuiEdit起動時にスプラッシュウィンドウが表示されるようにした。

- 追加

 マクロ機能を排除した機能制限版 nodoka64_limit.exe, nodoka_limit.exe

 モディファイヤーキー押しっ放し検出、解除機能 def option CheckModifier

 以上、よろしくお願いいたします。