[ruby-dev:3400] Re: sample of TkFont class

永井＠知能．九工大です．

>>>>> "t" == ttate  <[e-mail]> writes:
t> [e-mail]さん(07月23日21時)：
tadf> o 決りきった書式はないので、好きに構成することができる。
t> これが望まれるところですね。
tadf> o ボタンウィジェットの配列を設定することができる。
t> そのままRubyの配列をWedgetに渡して
t> -sideで左から詰めていけばできそう、、、

それをするんでしたら，多次元配列を渡して，
grid で配置する方がいいように思えますね．

tadf> o デフォルトのボタンウィジェットを設定することができる。
tadf> o リターンキーはデフォルトのボタンを選択したことと同義になる。

これは現状の tkdialog の機能と同じですね？

tadf> o ウィンドウマネージャを介して利用者にお伺いをたてたりしないで、勝手に
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
この部分，どういう意味かよくわかりません．
もう少し説明していただけませんか？

tadf> o アプリケイション全体、もしくは特定のウィンドウに関係して作用するグラ
tadf> ブがある。

アプリケーション全体の grab は現状の tkdialog の機能と同じですね？
「特定のウィンドウ関係して作用するグラブ」ってのは，
あるアプリケーションを構成する複数のウィンドウの内，
一部に対しては event 受け付けが停止され，
残りについてはまったく影響なく操作できるということですかね？
bindtags を用いれば実現できることでしょうけど，
これは本当に「ダイアログ」の機能として実現すべきでしょうかね？

tadf> o できれば単独でのアイコン化を許さない。

う〜む，これはどうなるのかなぁ．．．
確か wm コマンドなどにアイコン化禁止を指定できるような
サブコマンドはなかったと思うので，
アイコン化されたイベントを捉えて，強制的に deiconify することに
なるのかなぁ？？？

tadf> o ボタンが選択されたら、ダイアログは勝手に終了する (できれば禁止にもで
tadf> きる)。

勝手に終了する場合は，現状の tkdialog の機能と同じですね？
禁止にするということは grab の設定・解除のみを
行うということでしょうか？
ダイアログの目的というのは，情報を提示し，
ユーザからのアクションないし指定を確実に受け取ることに
あるのでしょうから，出しっぱなしのダイアログってのは，
本当に「ダイアログ」の機能としてあるべきなのでしょうか？

出しっぱなしのダイアログに何らかの操作があった場合，
それは何者が受け取ることになるのでしょうか？
イベント動作をさせるのであれば，
それは「ダイアログ」というものとは違ってくるような気がします．

ユーザによる操作を禁止するのなら，
画面からは消してしまう方が望ましいと思います．

tadf> o ダイアログは設定した配列に対応するインデックスをかえす。

ん？ これはどういうものでしょう？？？ よくわかりません．
戻り値の (種類の？) 指定は重要なことだと思いますが，
これを一般的に指定するにはどのような指定方法がいいと思われますか？

tadf> 本当にできるかどうかはわかりません (うーむ)。
t> 以上に挙げられたものなら結構できそうな気がします。
t> ;; 意見だけになってしまいます、、、m(_ _)m

そうですね．
上に挙げたもの程度でいいのでしたら，
もう少しインターフェースの設計をつめるだけで
実作業に入れるのかもしれません．
ですが，例えば，「ファイル選択ダイアログ」のように，
ちょっとした内部動作が必要なものはどう考えますか？
こういうものも，この汎化されたダイアログから
容易に作成できるようにすることを望まれているのでしょうか？
含めるのであれば，そのような機能定義はどうすべきかという
議論になりますし，含めないのであれば，
ならどこまでが汎化ダイアログのサポート範囲とすべきかという
議論になります．
自前で作成したウィジェットを渡すと
並べて表示してくれる程度のものなのか，それとも，
表示するウィジェットの種類 (と表示文字列などの設定) を
渡してやることでウィジェットの生成も含めて
行ってくれるものなのか，というようなことも含めての議論ですね．

t> もう少し抽象的にはあるユーザへのメッセージ
t> 伝達とその反応を確実に得るものがDialogには
t> 必要な要素の一つではないかと思います。

汎化ダイアログが伝達するメッセージとは現状程度で良いのか，
不足であるなら何が不足なのか．
また，反応の情報としては，どのボタンが押されたか程度でよいのか，
ユーザによってキーボード入力された文字列程度は必要なのか，
それとも，もっと多様な情報が必要なのか．
汎化ダイアログ自体では扱わなくてもいいが，
その子クラスでは扱うようにしたいとするなら，
どのようにして (どのような機構で) 扱えるようにするのか．
これらの点についてはどう思われますか？

t> ;; よってグラブは是非採り入れて欲しいです。

ユーザの反応を確実に得るという点では，
現在の tkdialog のローカルグラブというのは適切に思えます．

-- 
                                         永井 秀利 （九工大 知能情報）
                                             [e-mail]