YamaKen
yamak****@bp*****
2004年 2月 1日 (日) 02:31:13 JST
At Sat, 31 Jan 2004 22:47:59 +0900, tkng****@xem***** wrote: > On Sat, 31 Jan 2004 09:58:00 +0900 > YamaKen <yamak****@bp*****> wrote: > > > 基本的に問題ないと思いますが、mustではなくshouldであるべきだと思 > > います。 > > > > 例えばタブレットPCのようなデバイスでは、一度に複数ページ分の候補 > > を表示してスタイラスで直接指定できた方が便利だと思います。逆に画 > > 面の狭いPDA等ではあまり多くの候補を表示したくないかもしれません。 > > 表示する候補が少ない分には問題ないというか、どうしようもないと思うので > すが、もっとたくさん表示したい場合は、明示的に設定で増やすべきではないか > と思っています。もちろん、簡単に設定を行えるためのツールを用意しておくの > が前提の話ですが。 表示する候補数を決定する主導権をuim側ではなくUI側でも握れるよう にしておきたいという事です。 もう一つ別の例で説明します。候補ウィンドウ側で80文字*3行の範囲内 に候補を詰め込めるだけ詰め込んで表示したい、という場合には一度に 表示すべき候補数が不定になります(PDA用の予測入力IM向けにこのよう な候補ウィンドウが欲しいと思っています)。このような場合にはuim 側はUIから要求された候補を受動的に提供するだけであって欲しいと思 います。move_page_cb()のAPIを支持したのも、ページ送り方向の指定 しかないのでUI側が候補表示数の決定権を持てて都合が良いからです。 > > 良い機会なのでついでに候補関連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)); > 関数名はuim_set_candidate_picker_cbよりuim_set_candidate_cbの方が良い > と思います。たしかに候補は選ばせるために表示しているわけですが、ここでセ > ットしているのは候補を表示するためのコールバック関数なので。 言葉が足りませんでした。uim_set_candidate_cb()が設定しているコー ルバックは候補そのものではなく、候補ウィンドウを対象とした操作な のに'candidate'と候補そのものが対象であるかのような名前なので混 乱しました。私は以下の擬似コードのような脳内イメージを持っていま す。 class Candidate { char *str; char *index_str; char *annotation; }; class CandidateWindow { Candidate **candidates; public: void activate(intn nr, int nr_per_page_hint); void select(int index); void deactivate(void); }; 「候補をactivateする」のではなく「候補ウィンドウをactivateする」 というAPIなので、uim_set_candidate_window_cb()のように操作対象は 'candidate'ではなく'candidate_window'だと明示すべきだと思いまし た。 そして候補選択UIは必ずしもウィンドウではなく、Emacsのようにミニ バッファに表示される場合もあるので、よりgenericな存在として 'candidate_picker'という名前を考え、提案しました。確かにuimのAPI は候補をpickするという操作には関与しないんですが、「候補一覧を表 示しているオブジェクト」はユーザにとってpickerあるいはselectorと いった存在として認識されていると思います。browserやindicatorでは 違和感を覚えます。 > それと、仮引数名に関してですが、focus_cbよりselect_cbの方が良いと思い > ます。focusはGUIツールキットでよくでてくるので、紛らわしいそうです。 確かにfocusはまずいですね。selectで良いと思います。 > > > * 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のような候補選択が可能になります。 > > uim_candidate *uim_get_candidate(uim_context uc, int index, int > > disp_position_hint); void free_uim_candidate(struct uim_candidate > > *cand); > > > > 名前に関してですが、私の趣味としては以下のようになっていると分か > > りやすいと思いました。 > > ・index_strは引数のindex, disp_indexとの相関を連想させて紛らわし > > いのでaccelに変更(disp_indexとは通常は相関があるが、意識する必 > > 要はない) > > input methodによってはdisp_indexを無視してindexの数字をそのまま > index_strとして文字列として返してくることも考えられます。その際には表示 > されているのはアクセラレータではなく単なるindexなので、accelという変数名 > には反対します。 APIの意図を読み違えていました。単に連番を表示するために使う事も あるんですね。IMによっては候補選択用のキーを渡してくる事もあるだ けの話で。ちょっと考え直してみます。 > > ・disp_indexという名前はindexとの相関を連想させて紛らわしいので > > disp_positionに変更。さらに _hint を付けて参考情報である事を明 > > 示し、ucとindexがcandidateを得るためのソースだと強調する > > positionだとposition→位置→座標？ という感じに連想されそうな気がするの > でindexの方が良いと思うのですが、どうでしょう？index_for_displayとか。 positionがウィンドウそのものの表示位置等と誤解されやすいというの は納得できるので取り下げます。しかし、indexはどうしても避けたい 名前です。ちょっと苦しいですがdisp_precedence_hintはどうでしょう か? この場合のindexは単にn番目という意味で使っているんだと思いますが、 indexには索引とか対象物への関連づけのキーといった余計な概念が付 いてくるのでこの場合には不適切だと思います(indexの語源は「指さす もの、人差し指」だそうです)。 uim_get_candidate()の第2引数として渡されるindexがまさにcandidate を引き出すためのキーとして振る舞っているため(n番目という意味合い ももちろんありますが)、つられてdisp_indexにも同じような役割を仮 定してしまいます。少なくとも私はそうでした。candidate本体を引き 出すためのindexとは無関係なんだという事を名前で示しておく事で余 計な誤解を避ける事ができます。また、_hintを付ける事でcandidateへ 結び付くキーではない事を2重に示しています。 ちなみに、徳永さんの説明とAPIそのものだけではdisp_indexの意味が 理解できませんでした。「index= 15で disp_index = 5であるような状 況」やSKKの候補選択に必要、という情報からの推理が必要でした。 > > > * 候補文字列関連のcallback関数として move_page_cb(uim_context uc, > > > int direction) を加える。 > > > > > > 候補を1ページ分移動します。directionでどちらに移動するかを決めます > > > 。 > > APIは良いと思います。ただ、コールバックの名前はmoveよりshiftの方 > > が直感的じゃないかと思います。pageもwindow(覗き窓の意)とかscope > > とかにしたいところですが、windowだとウィジェットの方のwindowと紛 > > らわしいし、scopeもちょっと趣味に走りすぎな気もします。 > > 確かに意味からするとshiftの方が適切なのですが、shiftはshift keyとまぎ > らわしいんじゃないかと思います。紛らわしくない分moveの方が良いのではない > かと私は思うのですが、どうでしょう？ 個人的な感覚なんですが、moveだと表示されているページそのものがどっ かにすっ飛んで行きそうなイメージがあります。shiftは一般的な動詞 だし、対象がpageだと明示されている限りは大丈夫なんじゃないかと思 いますが、どうでしょう。他の方の意見も聞いてみたいところです。 > > 一応shift_scope_cb()を推しておきますが、pageという概念は候補ウィ > > ンドウから連想しやすいという利点があるのでshift_page_cb()も良い > > と思います。 > > scopeという単語には日常あまり馴染みがないので、わかりにくいのではない > かと思います。意味からするとたしかにscopeとかrangeとかの方が適切ではある > のですが。 > pageだと不適切ではあるもののわかりやすいと思うので、pageでいきます。た > ぶん。 ではpageでいいと思います。API全体を通してpageという概念を利用す るのはユーザの理解を助ける上で悪くないと思います。 ------------------------------- ヤマケン yamak****@bp*****
