TOKUNAGA Hiroyuki
tkng****@xem*****
2004年 1月 31日 (土) 22:47:59 JST
On Sat, 31 Jan 2004 09:58:00 +0900 YamaKen <yamak****@bp*****> wrote: > 基本的に問題ないと思いますが、mustではなくshouldであるべきだと思 > います。 > > 例えばタブレットPCのようなデバイスでは、一度に複数ページ分の候補 > を表示してスタイラスで直接指定できた方が便利だと思います。逆に画 > 面の狭いPDA等ではあまり多くの候補を表示したくないかもしれません。 表示する候補が少ない分には問題ないというか、どうしようもないと思うので すが、もっとたくさん表示したい場合は、明示的に設定で増やすべきではないか と思っています。もちろん、簡単に設定を行えるためのツールを用意しておくの が前提の話ですが。 > 良い機会なのでついでに候補関連APIの名前変更を提案します。現在は > 以下のようになっていますが、各コールバックに付いているbegin, > update, endとも意味が漠然としすぎていて動作モデルを知る手掛りと > して役に立ちません。また、候補ウィンドウ(ウィンドウとは限らない) > に関するAPIなのに'candidate'という名称なので混乱します。 候補に関する名称なのでcandidateで問題ないと思うのですが、具体的にどこ らへんが混乱しますか？ > int uim_set_candidate_picker_cb(uim_context uc, > void (*activate_cb)(void *ptr, int nr, int nr_per_page_hint), > void (*focus_cb)(void *ptr, int index), > void (*deactivate_cb)(void *ptr)); > > 私の場合は現在の名前を見た時に「begin〜endブロックの中でupdateを > 繰り返し呼んで候補文字列を充填する」という変な心理モデルを形成し > てしまい、ソースを読むまで理解できませんでした。また、動作モデル > を知った後も各コールバックの役割について明確なイメージが固着せず、 > ソースを見て思い出すような状態でした。 関数名はuim_set_candidate_picker_cbよりuim_set_candidate_cbの方が良い と思います。たしかに候補は選ばせるために表示しているわけですが、ここでセ ットしているのは候補を表示するためのコールバック関数なので。 それと、仮引数名に関してですが、focus_cbよりselect_cbの方が良いと思い ます。focusはGUIツールキットでよくでてくるので、紛らわしいそうです。 他は異論ありません。 > > * uim_get_candidateの仕様を > > > > char *uim_get_candidate(uim_context uc, int index); から > > void uim_get_candidate(uim_context uc, int index, int disp_index, > > char **index_str, char **cand, char > > **annotation); > > に変更する > > > > disp_indexは、何番目に表示される候補であるかを示します。例えば、 > > index= 15で disp_index = 5であるような状況が考えられます。 > > index_strはインデックスとして候補の右横に表示される文字列を意味しま > > す。candがこれまでの候補文字列で、annotationはその候補に対する注釈な > > どです。annotationが必要かどうかは悩むところです。 > > この仕様変更により、SKKのasdfのような候補選択が可能になります。 > > structにまとめて返す方がいいんじゃないでしょうか。今後項目を増や > したくなった時にもソース互換を崩さずに済みますし、 > uim_get_candidate()の呼び出し元で返値を個別にハンドリングする面 > 倒がなくなります。返ってきた値を別の関数やクラスに横流しするよう > な場合に便利です。 その通りですね。構造体にしておきます。 > uim_candidate *uim_get_candidate(uim_context uc, int index, int > disp_position_hint); void free_uim_candidate(struct uim_candidate > *cand); > > 名前に関してですが、私の趣味としては以下のようになっていると分か > りやすいと思いました。 > > ・uim_get_candidate()の主目的は候補の文字列を得る事なので、cand > は返値群の中で先頭にあるべき。そうでないと関数が果たす役割のイ > メージがあやふやになる。原案では表示される要素順に返値が並んで > いるが、論理的重要度順が望ましい > > ・index_strは引数のindex, disp_indexとの相関を連想させて紛らわし > いのでaccelに変更(disp_indexとは通常は相関があるが、意識する必 > 要はない) input methodによってはdisp_indexを無視してindexの数字をそのまま index_strとして文字列として返してくることも考えられます。その際には表示 されているのはアクセラレータではなく単なるindexなので、accelという変数名 には反対します。 > ・disp_indexという名前はindexとの相関を連想させて紛らわしいので > disp_positionに変更。さらに _hint を付けて参考情報である事を明 > 示し、ucとindexがcandidateを得るためのソースだと強調する positionだとposition→位置→座標？ という感じに連想されそうな気がするの でindexの方が良いと思うのですが、どうでしょう？index_for_displayとか。 > > * 候補文字列関連のcallback関数として move_page_cb(uim_context uc, > > int direction) を加える。 > > > > 候補を1ページ分移動します。directionでどちらに移動するかを決めます > > 。 > > これはuim_set_candidate_cb()で設定するコールバックでいいんですよ > ね? そうです。 > APIは良いと思います。ただ、コールバックの名前はmoveよりshiftの方 > が直感的じゃないかと思います。pageもwindow(覗き窓の意)とかscope > とかにしたいところですが、windowだとウィジェットの方のwindowと紛 > らわしいし、scopeもちょっと趣味に走りすぎな気もします。 確かに意味からするとshiftの方が適切なのですが、shiftはshift keyとまぎ らわしいんじゃないかと思います。紛らわしくない分moveの方が良いのではない かと私は思うのですが、どうでしょう？ > 一応shift_scope_cb()を推しておきますが、pageという概念は候補ウィ > ンドウから連想しやすいという利点があるのでshift_page_cb()も良い > と思います。 scopeという単語には日常あまり馴染みがないので、わかりにくいのではない かと思います。意味からするとたしかにscopeとかrangeとかの方が適切ではある のですが。 pageだと不適切ではあるもののわかりやすいと思うので、pageでいきます。た ぶん。 > 何だか色々と偉そうな事を書きましたが、趣味の領域ではついつい熱が > 入ってしまうのでご勘弁ください。反論も歓迎します。 熱が入る程に楽しいのだ、ということで。楽しんで開発していきましょう！ -- 徳永拓之 http://kodou.net/
