YamaKen
yamak****@bp*****
2005年 1月 30日 (日) 11:46:00 JST
ヤマケンです。 At Sun, 30 Jan 2005 06:53:54 +0900, tkng****@xem***** wrote: > > わかりにくい文章ですいません。正直、私の頭の中もまだ割とごちゃごちゃし > てます。 十分よくわかりますよ。ライブラリ内部の設計なんかと違ってGUIまわ りは他人の問題意識も理解しやすいですね。 > On Wed, 26 Jan 2005 20:56:05 +0900 > YamaKen <yamak****@bp*****> wrote: > > > 設定項目間の関連性を示すためのサブグループをツリー上に分類すると > > 細分化されすぎて使い勝手が悪くなります。 > > > > 例えば、"Specify default IM"と"Default input method"はこの2つだ > > けで"Default input method"サブグループを構成していて、"Specify > > default IM"の有効/無効が"Default input method"の有効/無効を制御 > > するという関連性を直感的に理解させる事を目的にしています。 > > これは"Specify default IM"の有効/無効が"Default input method"の有効/無 > 効を制御するために必要な事なのでしょうか？それとも、理解を助けるためだけ > なのでしょうか？後述しますが、必要なのでなければ、サブグループはグループ > の分類に使わせてもらえると実装がかなり助かります。 視認性を上げ、理解を助けるだけです。しかしこれは直感的GUIを実現 するために重要な事だと思っています。徳永さんは全く有用性を感じま せんか? それと意図が伝わってないかもしれないんで補足しますが、"Default input method"の無効化というのはウィジェットをinactiveにして編集 自体を禁止する事を想定しています(外観が変化し、値は見えるけどク リックしても反応しない)。 そして、"Specify default IM"の設定値を変更するとコールバックがか かって、"Default input method"の設定用ウィジェットの active/inactive状態を通知します。uim_custom->is_activeがこの状態 を指定します。 ユーザは"Specify default IM"のチェックボックスをプチプチとトグル させるとそれに同期して"Default input method"のウィジェットが無効 化/有効化されるのを視覚的に確認し、その因果関係からこの2つの項目 の関連性モデルを理解します。この時サブグループによる囲い込みは暗 黙に変化の影響範囲情報をユーザに与え、理解を助けます。 > > 分類については徳永さんの言うように「SKK、SKK(キー設定)」といった > > トップレベルでの手動分割で調整する事を設計段階から意図しています。 > > これはツリー状の構造化が必要なほどにはグループ数が多くない事を見 > > 越しての事ですが、項目が増えて使いづらくなってきたら"Enabled > > input methods"で有効になっているIMの設定グループだけ表示するよう > > にしたいと思います。これはuim-pref側では各種コールバックに対応し > > てもらえれば後はScheme側で実現できます。 > > まだどういうコールバックを実装すればいいのかいまいちよくわかってないの > で、どういう機能を実装すればいいのか教えていただけますか？ コールバックはcustom_cb, custom_group_cb, custom_global_cbの3種 がありますが、どれもScheme側で設定の変更があった事を知らせるだけ です。通知を受け取った側は値の反映、要はリロードする事が期待され ます。 3種の違いは更新範囲です。それぞれ以下のようになっています。 - custom_cb 個々のcustom variable単位の更新を知らせる。全てのcustom variableに対して設定する事が求められる。 - custom_group_cb 1つのグループ全体の更新を知らせる。そのグループに属するcustom variable項目の増減が行われる。これも全てのグループに対して要設 定。 - custom_global_cb custom APIで管理される全ての設定情報の更新を知らせる。グループ の増減が行われる。 これらのコールバックは、ある設定項目の変化が他の項目も変化させる ような場合に使われます。例えばenabled-im-listを編集すると default-im-nameに設定可能な項目がそれに同期する等。 > > advancedのような分類目的でかつ隠す事にUI的意義のあるサブグループ > > は足永さん案でいいと思います。advancedだけは元々そういった特別扱 > > いを受ける事を意図していますし、Global key bindingsもadvancedを > > 除けば多くの環境で初期サイズのウィンドウに収まります。 > > サブグループを2つの目的に使うのは却って混乱すると思います。サブグルー > プは項目間の関連を示すものとするなら、分類目的にはサブグループは使わず、 > グループ名を変えてしまう方がいいと思います。（(skk advanced)とするよりも > (skk-advanced)とするということです。） (skk advanced)より(skk-advanced)というのは一つの手ですが、私が分 類目的と言ったのは単に関連性明示目的と対比しただけで、ツリー状階 層管理の事を指してるわけではないです。 例えば以下のようなサブグループは分類目的です。advanced以外の分類 目的サブグループはこういった小規模なものを想定しているので、ツリー 状に細分化されてしまうと不便になります。 Candidate window Use candidate window Conversion key press count to show candidate window Number of candidates in candidate window at a time Select candidate by numeral keys 要は目的によらず1つのパネル内で小項目をまとめる事を意図していま す。パネル自体の分割に使う事は意図していません。 ただ、advancedについては正直どうすべきか明確な意見が持てていませ ん。グループ内でボタンによってcollapse/expandしたり別ウィンドウ が開くようなインタフェイスを想定していましたが、Global keysあた りの項目数の多いそれは独立したグループとした方が使い勝手がよさそ うです。が、その場合は親パネル内でのcollapse/expandではなく独立 したグループとして隠したり表示したりといった事が必要になります。 advancedは必ず独立したグループとするなら解決は簡単ですが、 advanced内に1つ2つしか項目が無いような場合には親パネル内にあった 方が便利に思えます。 > ただ、これをすると「Enabled input methodsで有効になっているIMの設定グ > ループだけ表示」を実装できなくなりそうに見えます。 この関連づけの管理と表示制御はScheme内に隠蔽できます。uim-pref側 ではコールバックにさえ対応してもらえれば自動的に対応できます。 > 次に、分類目的にサブグループを使った場合を考えてみました。私は分類目的 > にサブグループを使った方がいいと思っています。そうすると使えると問題が非 > 常に簡単に解決できそうなので。 > > 現状のサブグループの実装は分類目的として十分に使用可能な機能を既に備え > ているように見えるので、「サブグループはグループの分類に使いましょう！」 > と合意すれば（そしていくつかのxxx-custom.scmをいじれば）、後はサブグルー > プをツリー状に表示するようにすれば、それで問題が解決できるように見えます。 ここで徳永さんが言っている分類というのはツリー状の階層化の事です よね? 私としては上述のようにパネル内での小項目が必要だと思っているので 転用には賛成できません。小項目としてのサブグループの必要性につい て議論が終わったら改めて検討しましょう。 > これを今見てふと「候補ウィンドウを使わない」なんてマニアックな設定は > advanced送りでいいんじゃないかと思いましたが、そこら辺はまた別メールにま > とめます。 advancedとかの分類はとりあえず適当にやっつけただけなんで、おかし いと思ったらどんどん変更しちゃってください。 ------------------------------- ヤマケン yamak****@bp*****
