From t-suwa ＠ users.sourceforge.jp Sat Jul 15 10:33:54 2006 From: t-suwa ＠ users.sourceforge.jp (Tomotaka SUWA) Date: Sat, 15 Jul 2006 10:33:54 +0900 Subject: [aquaskk-dev 59] =?iso-2022-jp?b?QXF1YVNLSyAzLjEgGyRCJWolaiE8GyhC?= =?iso-2022-jp?b?GyRCJTkbKEI=?= Message-ID: 諏訪です。 AquaSKK 3.1 をリリースしました。 http://sourceforge.jp/projects/aquaskk/files/?release_id=20950#20950 リリースタグは release-3_1 です。 ▼追加・改善された機能 ・数値変換をサポート ・ことえり辞書で「;」が使えるように改善 ・KeyBindings に対応 ・SKK 辞書：ファイルが更新されていたらロードし直すように改善(10分毎) ▼不具合修正 ・skkserv が不意に切断されると、ディスクフルになる不具合を修正 ・補完時に空振りする現象を修正 ・SKK-JISYO.jinmei がダウンロードできない不具合を修正 ・デュアルディスプレイ使用時に候補ウィンドウ位置が不正になる不具合を修正 - * - 今後の開発スケジュールについては、もうちょっと考えをまとめてからメール します。 ではよろしくお願いします。 -- Tomotaka SUWA From t-suwa ＠ users.sourceforge.jp Sat Jul 22 11:27:43 2006 From: t-suwa ＠ users.sourceforge.jp (Tomotaka SUWA) Date: Sat, 22 Jul 2006 11:27:43 +0900 Subject: [aquaskk-dev 60] =?iso-2022-jp?b?GyRCOiM4ZSROMytILyRLJEQkJCRGGyhC?= Message-ID: 諏訪です。 次の課題は自動ダイナミック補完になるのですが、これを実現するにあたり、 現在の AquaSKK のコンポーネント部分の作り、実際のコードを何度も確認・検 討してみました。 その過程で、継承関係に着目したクラス図を起こしました。 # 所有関係を入れるとゴチャゴチャするので省いています。間違っているとこ # ろがあれば訂正するので教えて下さい。 http://aquaskk.sourceforge.jp/images/inputmode_hierarchy.png 図の中央あたりの IMSessionInputMode が、アプリケーション単位で作成され る AquaSKK のインスタンスで、窓口として動作します。 この設計のベースになっているのは、機能中心のアプローチだと思います。機 能単位でクラスを抽出し、その中で個別に状態を管理しています。 一方で、状態中心のアプローチも有効ではないかと考え、試しに状態遷移図を まとめてみました。まだ完全ではありませんが、とりあえずの雰囲気はつかめ ると思います。 http://aquaskk.sourceforge.jp/images/statechart.png 実際のコードでは、各ボックス単位でクラス化するイメージになります。入れ 子構造はクラスにするか、関数ポインタにするか、悩みどころです。 また、「確定入力モード」の部分はかなり端折って書いているので、実際には もっと複雑になると思います。 当然のことながら一筋縄ではいかず、何度も試行錯誤が必要になるでしょう。 ただ、状態中心アプローチのメリットである、状態が機能の中に埋もれない、 状態が複数の機能に分散しないという点は、そういったマイナス要因を打ち消 すほど魅力的で、最終的にはメンテナンス性の向上が期待できます。 逆に言うと、機能が状態の中に埋もれる、機能が複数の状態に分散することに なりますが、これは機能側の独立性と再利用性を高めることにも繋がるわけで、 一石二鳥の相乗効果が期待できるのではないかと、妄想しています ;-) ということで、自動ダイナミック補完を実装する前に、状態中心アプローチで コンポーネント部分を書き直したいと思っています。 おおまかな進め方は以下の通りです。 (1) 状態中心コンポーネントの追加(〜 10月末) 既存のコードは温存したまま、新しいコードを追加していきます。 環境設定にオプションを追加し、実績のある現在のコード(=レガシーエン ジン)を使うのか、状態中心のコード(=新エンジン)を使うのかを選択でき るようにします。 (2) 互換性の確保(〜 12月末) レガシーエンジンと新エンジンの互換性が 100% になるまで、ひたすらテ ストを繰り返します。 (3) 自動ダイナミック補完の実装(〜 来年 3 月末) 互換性が 100% になったら、新エンジン側に自動ダイナミック補完を実装 していきます。 (4) レガシーエンジンの切り離し(〜 ？) 新エンジンが充分にこなれ、安定度・信頼性の面で問題がないと判断でき た時点で、古いコードを取り除きます。 - * - 新エンジンの開発は、ブランチを切って進めるつもりです。何かご意見などが あればよろしくお願いします。 -- Tomotaka SUWA