TOKUNAGA Hiroyuki
tkng****@xem*****
2005年 1月 30日 (日) 14:07:47 JST
On Sun, 30 Jan 2005 11:46:00 +0900 YamaKen <yamak****@bp*****> wrote: > > > 分類については徳永さんの言うように「SKK、SKK(キー設定)」といった > > > トップレベルでの手動分割で調整する事を設計段階から意図しています。 > > > これはツリー状の構造化が必要なほどにはグループ数が多くない事を見 > > > 越しての事ですが、項目が増えて使いづらくなってきたら"Enabled > > > input methods"で有効になっているIMの設定グループだけ表示するよう > > > にしたいと思います。これはuim-pref側では各種コールバックに対応し > > > てもらえれば後はScheme側で実現できます。 > > > > まだどういうコールバックを実装すればいいのかいまいちよくわかってな > > いので、どういう機能を実装すればいいのか教えていただけますか？ > > コールバックはcustom_cb, custom_group_cb, custom_global_cbの3種 > がありますが、どれもScheme側で設定の変更があった事を知らせるだけ > です。通知を受け取った側は値の反映、要はリロードする事が期待され > ます。 > > 3種の違いは更新範囲です。それぞれ以下のようになっています。 (snip) > これらのコールバックは、ある設定項目の変化が他の項目も変化させる > ような場合に使われます。例えば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をいじれば）、後 > > はサブグループをツリー状に表示するようにすれば、それで問題が解決でき > > るように見えます。 > > ここで徳永さんが言っている分類というのはツリー状の階層化の事です > よね? > > 私としては上述のようにパネル内での小項目が必要だと思っているので > 転用には賛成できません。小項目としてのサブグループの必要性につい > て議論が終わったら改めて検討しましょう。 問題が飲み込めたように思います。私はヤマケンさんの「視覚的に理解を助け る」というのがxxx-custom.scmを読む際の理解を助けることだと解釈していたの で、そこまで気をつかわなくてもいいだろうと思っていました。 つまり、問題はツリー上に分類するためのカテゴリ分けと、その中でグループ 化するためのカテゴリ分けの2つの分類が必要であるのに対し、1つしかカテゴリ 分けの手段が存在しないという事ですね。 というわけで、これを解決するために、もうひとつカテゴリ分けする機能が define-customにあればよいと。 解決案： (a) define-customのグループ指定で、1番目をグループ、2番目をサブグループ（ ツリー化用）、3番目をフレーム（パネル内での分類用）とする。 '(skk advanced xxx) みたいな感じです。この方法だとskkのパネルに分類したいときは '(skk #f xxx) みたいな感じにしないといけないのがちょっといや。 (b) パネル内で分類するための項目をdefine-customに追加する。 (define-custom 'skk-commit-candidate-by-label-key? #t '(skk advanced) 'xxx;; 全てのアイテムはなんらかのパネルのカテゴリに分類されるべきで ;; ある（by GNOME HIG） '(boolean) (_ "Commit candidate by heading label keys") (_ "long description will be here.")) みたいな感じです。 どちらにしても、パネルの階層化は必要で、サブグループはそれに使われるべ きだというのが私の意見です。（ここでのサブグループはツリーを構成するため の分類を指しています。）いや、正直、パネルの階層化が必要かと言うとよくわ からないですが、ここでは必要であるとしておきます。 -- 徳永拓之 tkng****@xem***** http://kodou.net/
