[Anthy-dev 508] Re: uimのAPIの拡張

Zurück zum Archiv-Index

YamaKen yamak****@bp*****
2004年 2月 5日 (木) 01:21:59 JST


At Wed, 4 Feb 2004 22:54:38 +0900,
tkng****@xem***** wrote:
> 
>  長くなってきたので、もしかしたら答えられてない大事な論点があるかもしれ
> ません。そういう事があったら、適当に蒸し返してください。

名前に関する議論は大好きなので、必要なところは喜んで蒸し返させて
頂きます。

> On Sun, 01 Feb 2004 02:31:13 +0900
> YamaKen <yamak****@bp*****> wrote:
>  なるほど。私は候補も候補ウィンドウも同一視してると言うよりあんまり深く
> 考えた事もありませんでした。ただ、pickerは選択するというよりも拾いあげて
> 来るというイメージが強いので、selectorでいこうと思います。
> 
> > >  それと、仮引数名に関してですが、focus_cbよりselect_cbの方が良いと
> > > 思います。focusはGUIツールキットでよくでてくるので、紛らわしいそうで
> > > す。
> > 
> > 確かにfocusはまずいですね。selectで良いと思います。
> 
>  良く考えたら、マウスでの候補選択のために既にuim_select_cbという名前が
> 使われていました。どうしようかちょっと悩み中です。

selectorに対して設定されるコールバックだからselectで大丈夫なよう
な気もしますが、uim_select_cbというのはどんな定義になるんでしょ
うか? 今はまだ無いですよね。

> > > > ・disp_indexという名前はindexとの相関を連想させて紛らわしいので
> > > >   disp_positionに変更。さらに _hint を付けて参考情報である事を明
> > > >   示し、ucとindexがcandidateを得るためのソースだと強調する
> > > 
> > >  positionだとposition→位置→座標? という感じに連想されそうな気がす
> > > るのでindexの方が良いと思うのですが、どうでしょう?
> > > index_for_displayとか。
> > 
> > positionがウィンドウそのものの表示位置等と誤解されやすいというの
> > は納得できるので取り下げます。しかし、indexはどうしても避けたい
> > 名前です。ちょっと苦しいですがdisp_precedence_hintはどうでしょう
> > か?

>  新しいのを思い付いたんですが、アクセラレータのためのヒントということで
> accel_hintっていうのはどうでしょう?

今のところ他の用途に使うアテがなさそうなんで、accelを入れた方が
わかりやすいですね。もうちょっと目的を明示して
accel_enumeration_hint とかはどうでしょう。ちょっと長いですが。

この情報に基づいて返ってくる以下の文字列についてもペアで考えてみ
ました。

At Sun, 01 Feb 2004 02:31:13 +0900,
yamak****@bp***** wrote:
> 
> At Sat, 31 Jan 2004 22:47:59 +0900,
> tkng****@xem***** wrote:
> > > ・index_strは引数のindex, disp_indexとの相関を連想させて紛らわし
> > >   いのでaccelに変更(disp_indexとは通常は相関があるが、意識する必
> > >   要はない)
> > 
> >  input methodによってはdisp_indexを無視してindexの数字をそのまま
> > index_strとして文字列として返してくることも考えられます。その際には表示
> > されているのはアクセラレータではなく単なるindexなので、accelという変数名
> > には反対します。
> 
> APIの意図を読み違えていました。単に連番を表示するために使う事も
> あるんですね。IMによっては候補選択用のキーを渡してくる事もあるだ
> けの話で。ちょっと考え直してみます。

heading_label はどうでしょう。APIとしては「候補文字列の見出しと
して表示して欲しい」という見た目の規定に留め、内容については関知
しないという事で。IM次第で中身がaccelの事もあれば、単に候補の連
番の場合もある、品詞情報を表示したって構わないという事で。

ここらへんは、先日preedit絡みの話題で出た「APIで見ためと意味のど
ちらを規定するべきか」という問題に関わってきますが、個人的には当
面見た目の規定に留めて経験を積んだ方が良いと思います。候補情報全
体を意味モデルに従って規定してしまうと、モデルが不適切だった場合
に悲劇なので。annotationは意味の規定ですが、これはとりあえずSKK
でしか使われないと思うので、意味モデルの経験を積む実験台にちょう
どいいんじゃないかと思います。

-------------------------------
ヤマケン yamak****@bp*****



Anthy-dev メーリングリストの案内
Zurück zum Archiv-Index