YamaKen
yamak****@bp*****
2004年 12月 16日 (木) 08:17:42 JST
ヤマケンです。 しばらく中断してしまいましたが、uim-custom.hとして定義した新 custom APIの実装を片付けてしまおうと思います。 以下のメール以後なにか意見の変わった方はお知らせください。 他にもメールの返答等が滞っていますが、順次返答してゆきますので、 すみませんがしばらくお待ちください。 At Mon, 15 Nov 2004 19:40:03 +0900, yamak****@bp***** wrote: > > At Fri, 12 Nov 2004 23:22:15 +0900, > mover****@hct***** wrote: > > > ・custom API改訂 > > > > > > uim-custom.hとしてcommit済。表さん、足永さん、kzkさんの賛同が > > > 得られればヤマケンが中身を実装する。 > > 足永さん、kzkさんとも特に問題なしとの事で、表さんからも概ねOKと > いう声を聞いたので順次実装に移りたいと思います。 > > > > ・設定保存方法変更 > > > > > > 現在のsumikaは ~/.uim に直接設定を上書きするが、[Anthy-dev > > > 719]で述べた通り、以下のように変更する。これはuim-custom.hの > > > uim_custom_save()として実装する予定。 > > > > > > - custom API経由で行った設定は ~/.uim.d/user-custom.scm (仮称) > > > に保存 > > > > > > - ~/.uim はユーザが手書きで設定を行うための専用ファイルとする > > > > > > - ~/.uim.d/user-custom.scm と ~/.uim では ~/.uim の方が後から > > > 読み込まれ、結果として手書き設定の方が優先される > > > > > > - ~/.uim の設定はsumika起動時にも読まれるので、GUI設定の初期値 > > > に影響を与える。つまり一度sumikaで設定をsaveすると ~/.uim の > > > 内容(のうちdefine-customで定義された設定)が > > > ~/.uim.d/user-custom.scm にコピーされる事になる > > 了解しました。これでOKです。 > > ~/.uim.d はcustom API以外にも使い道があると思うので、以下のよう > に変更したいと思います。何か意見のある方はお願いします。 > > ・custom APIがいじる設定は~/.uim.d/customs/以下に格納 > > ・group名を基本として別々のファイルに分割してセーブする > > ~/.uim.d/customs/custom-generic.scm > ~/.uim.d/customs/custom-japanese.scm > ~/.uim.d/customs/custom-anthy.scm > ~/.uim.d/customs/custom-prime-key.scm > ・ > ・ > ・ > > > > ・uim-pref作成 > > > > > > uim-custom.hを利用したアプリケーションとしてsumikaを元に作り直 > > > す。ヤマケンは基本的に作業せず補完程度。現在のsumikaに加えて、 > > > 以下のような追加仕様が必要。 > > 了解しました。uim-pref-qtを実装してみるのが楽しみです。 > > もし余裕があればのお願いなんですが、Linuxザウルスでも動くと嬉し > いのでなるべくQt2の範囲内のclass, methodだけで実装できないでしょ > うか? Qt2での実際の動作確認までは不要です。 > > もちろん必須ではないです。Qt4でcompatに格下げされたAPIを使わない > だけでもだいぶ差は小さくなるでしょうし。 > > > > 以下は余力があればuim-pref側で実現して欲しい機能。 > > この部分は説明不足でした。足永さんの疑問にも答える形で以下に追補 > します。 > > > > * キー定義の手段として、キーのcapture、文字列として入力の他 > > > にgeneric-cancel-key?等のsymbolからも選択可能にしたい > > これって"generic-cancel-key?"っていう項目をキー定義に使えるように > > したいという意味ですよね？需要有りますかね...ちょっと疑問です。 > > > > > * ただし、上記設定手段は普通の人には仕組みが理解しづらいため、 > > > 通常は存在を隠しておき、keybind subgroupに属する「高度な設 > > > 定」というbool custom variableにチェックを入れた時だけ設定 > > > 可能にする > > 内部に精通してる人間以外には"generic-cancel-key?"っていうシンボルが > > 有る事を隠した方が良いと思うのですが。 > > custom APIにおけるsymbolはhuman-readableなラベルとdescriptionを > 持っているので、ユーザには「[汎用] キャンセル」や「[Anthy] キャ > ンセル」といった形で見せる事を意図しています。なので、実際に > "generic-cancel-key?"という文字列がGUI上に現れるわけではありませ > ん。 > > #[汎用]はgenericの訳語ですが、これが最適とは思っていません > > 例として現在のsumikaには"Default input method"という設定項目があ > りますが、これがsymbolです。各symbolはリスト中ではラベルとして表 > 示されます。例えば、ipaというシンボルはリスト中で"International > Phonetic Alphabet"と表示されています。 > > > こうするよりむしろ、全体のIM の設定の所で"generic-*-key?"を設 > > 定できるようにした方が良いと思うのですが。普通の人なら > > "anthy-on-key?"を個別にいぢるんじゃなくて"generic-on-key?"をい > > ぢりたいでしょう。 > > この機能で意図しているのはまさにそういった用途です。genericグルー > プで「[汎用] キャンセル」というキーバインドを設定し、それを他の > グループ中のキーバインド設定に流用できるようにという事です。要は > 以下のような設定をGUIで行うための機能です。 > > (define-key anthy-on-key? '("<Control>j" "<Control>J" generic-on-key?)) > > ただ、それでは自由度が高すぎて普通の人には使いにくいと思うので > anthyグループの「キャンセル」キーのような各キーバインド設定毎に > 「[汎用]の設定に従う」というチェックボックスを設けて、チェックし > た時には「キャンセル」キーバインドの設定を無効化するようにしては > どうかと思います。kzkさんの意図してるのはこっちに近いんじゃない > かと思いますがどうでしょう。 > > なお、チェックボックスとキーバインド設定用widgetとの連携や表示上 > の並び等は自由に定義できるので、後から試行錯誤しても大丈夫です。 > widgetの仕様が問題です。 > > > At Fri, 12 Nov 2004 05:31:04 +0900, > ashie****@homa***** wrote: > > > - subgroupによるグループ内グルーピングを実装 > > > > グルーピングについては了解ですが、枠で囲むのはGNOME HIG的にはあまりよろ > > しくありません。 > > > > http://developer.gnome.org/projects/gup/hig/2.0/controls-frames.html > > > > uim全体のポリシーとしてHIGに従うかどうかはまだ定かではありませんが、特に > > 違反しなければならない理由がなければ従ったほうが良いと思っています。 > > 異論のある方はお知らせ下さい。 > > グルーピングされている事が視覚的に認識できれば別表現でも全く構い > ません。 > > ただ、そのURLの例だと"Category 1"と表示している文字列と一般の文 > 字列との差異化がちょっと弱いように感じられます。フォントの問題も > あって難しいですが、もっと太く大きなフォントで表示して、カテゴリ > 間のスペースももう少し広くしないと私の個人的感覚では区分けされて > いるように見えません。 > > まあ実データで表示してみるとまた印象が違うと思うので、ヤマケンが > こんな事を言っていたという程度に頭の片隅にでも置いておいてくださ > い。 ------------------------------- ヤマケン yamak****@bp*****
