TOKUNAGA Hiroyuki
tkng****@xem*****
2005年 1月 30日 (日) 06:53:54 JST
わかりにくい文章ですいません。正直、私の頭の中もまだ割とごちゃごちゃし てます。 On Wed, 26 Jan 2005 20:56:05 +0900 YamaKen <yamak****@bp*****> wrote: > At Wed, 26 Jan 2005 16:13:02 +0900, > ashie****@homa***** wrote: > > On Wed, 26 Jan 2005 07:07:48 +0900 > > TOKUNAGA Hiroyuki <tkng****@xem*****> wrote: > > > SKKに関してはSKK、SKK（上級者用設定）みたいな感じで2つに分けよう > > > と思います。Global key bindingsに関してはどうしようか悩んでいます > > > 。スクロールバーは付けたくないのですが、各設定項目のグループ化が簡 > > > 単にはできなさそうなので。スクロールバーか。スクロールバーしかない > > > のか。 > > > > スクロールバーもタブも視認性が悪いので、私個人としては好きではありま > > せん。できればサブグループをツリー状に表示したいです。 > > 設定項目間の関連性を示すためのサブグループをツリー上に分類すると > 細分化されすぎて使い勝手が悪くなります。 > > 例えば、"Specify default IM"と"Default input method"はこの2つだ > けで"Default input method"サブグループを構成していて、"Specify > default IM"の有効/無効が"Default input method"の有効/無効を制御 > するという関連性を直感的に理解させる事を目的にしています。 これは"Specify default IM"の有効/無効が"Default input method"の有効/無 効を制御するために必要な事なのでしょうか？それとも、理解を助けるためだけ なのでしょうか？後述しますが、必要なのでなければ、サブグループはグループ の分類に使わせてもらえると実装がかなり助かります。 > 分類については徳永さんの言うように「SKK、SKK(キー設定)」といった > トップレベルでの手動分割で調整する事を設計段階から意図しています。 > これはツリー状の構造化が必要なほどにはグループ数が多くない事を見 > 越しての事ですが、項目が増えて使いづらくなってきたら"Enabled > input methods"で有効になっているIMの設定グループだけ表示するよう > にしたいと思います。これはuim-pref側では各種コールバックに対応し > てもらえれば後はScheme側で実現できます。 まだどういうコールバックを実装すればいいのかいまいちよくわかってないの で、どういう機能を実装すればいいのか教えていただけますか？ > advancedのような分類目的でかつ隠す事にUI的意義のあるサブグループ > は足永さん案でいいと思います。advancedだけは元々そういった特別扱 > いを受ける事を意図していますし、Global key bindingsもadvancedを > 除けば多くの環境で初期サイズのウィンドウに収まります。 サブグループを2つの目的に使うのは却って混乱すると思います。サブグルー プは項目間の関連を示すものとするなら、分類目的にはサブグループは使わず、 グループ名を変えてしまう方がいいと思います。（(skk advanced)とするよりも (skk-advanced)とするということです。） ただ、これをすると「Enabled input methodsで有効になっているIMの設定グ ループだけ表示」を実装できなくなりそうに見えます。 これを解決するためには - 各グループの親グループを指定できるようにする - 実装がややこしくなりそう - advanced flagというものをdefine-customの引数に追加する - 分類は「上級者向け/それ以外」程度しか思い付かないので の2点を思い付きます。実装コストを考えると、後者でいくべきだと思います が、正直どちらの案もあまり好みではありません。 次に、分類目的にサブグループを使った場合を考えてみました。私は分類目的 にサブグループを使った方がいいと思っています。そうすると使えると問題が非 常に簡単に解決できそうなので。 現状のサブグループの実装は分類目的として十分に使用可能な機能を既に備え ているように見えるので、「サブグループはグループの分類に使いましょう！」 と合意すれば（そしていくつかのxxx-custom.scmをいじれば）、後はサブグルー プをツリー状に表示するようにすれば、それで問題が解決できるように見えます。 というような議論はサブグループが"Specify default IM"の有効/無効が "Default input method"の有効/無効を制御するために必要ではないという仮定 に基づいているので、この仮定が間違っているなら意味が無いです。そのときは advanced flagでいくことを提案します。以下のような感じを意図しています。 ;; advanced な場合 (define-custom 'skk-commit-candidate-by-label-key? #t '(skk) 'advanced '(boolean) (_ "Commit candidate by heading label keys") (_ "long description will be here.")) ;; そうでない場合 (define-custom 'skk-use-candidate-window? #t '(skk) '(boolean) (_ "Use candidate window") (_ "long description will be here.")) これを今見てふと「候補ウィンドウを使わない」なんてマニアックな設定は advanced送りでいいんじゃないかと思いましたが、そこら辺はまた別メールにま とめます。 -- 徳永拓之 tkng****@xem***** http://kodou.net/
