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

ふなばです。

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

僕は基本的に普通のウィンドウのようにしたいと思っていて、ダイアログを間
接的に構成する、ということはしたくないです。それをしちゃうと、本家
tkdialog と同じようなことになってしまいませんか。

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

そういうことです。基本的には、これに限らず tkdialog にある、本質的なと
ころを抜きだすという方針で書いているので。

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

どう表現すべきか判らないので、こういうふうになっちゃったんですが、もう
ちょっとちゃんと説明します。

簡単にいうとと、これについても tkdialog と同じだと思います。たとえば、
ウィンドウマネージャ twm であれば、とくに指示がなれば、 ウィンドウをど
こに配置するのか、利用者にお伺いをたてますよね (指示のしかたはいろいろ
あります)。ダイアログではこれをしないように、指示をしてほしいわけです。
ダイアログの性質上、例外なく、勝手にでてきてほしいわけです。ところで、
なかには olwm のように、どんなものでも、とりあえず勝手に配置する方針の
ものもあります (つまりは、ウィンドウの配置というのは基本的にウィンドウ
マネージャがすべき仕事なんでしょうね、きっと)、 そういう場合は、違いが
わからないですね。

>tadf> o アプリケイション全体、もしくは特定のウィンドウに関係して作用するグラ
>tadf> ブがある。
>
>アプリケーション全体の grab は現状の tkdialog の機能と同じですね？
(以下略)

グラブについては、僕は tkdialog と特別に違いを求めるところはないです。
よくわからないので、永井さんの解釈で、きっとよいと思います。

>tadf> o できれば単独でのアイコン化を許さない。
>
>う〜む，これはどうなるのかなぁ．．．

これは、おいといてもよさそうです。でも、ダイアログの性質上、こうなって
いるとよさそうに思えました。アイコン化できないのではなくて、あくまで、
単独ではできない、ということですかね。

>tadf> o ボタンが選択されたら、ダイアログは勝手に終了する (できれば禁止にもで
>tadf> きる)。
>
>勝手に終了する場合は，現状の tkdialog の機能と同じですね？
>禁止にするということは grab の設定・解除のみを
>行うということでしょうか？

勝手に終了するのは tkdialog と同じです。禁止というのは、一時的に禁止に
できるにもできる、ということだと思ってください。より一般化したダイアロ
グでは、そこからさらにダイアログを生成する可能性があると考えたからです。
ということで、出しっぱなしということではありません (ひょっとして、これ
は考えなくてもいいかもしれません)。

>tadf> o ダイアログは設定した配列に対応するインデックスをかえす。
>
>ん？ これはどういうものでしょう？？？ よくわかりません．

永井さんは「得る」っていってましたっけ、インデックスを得るにしておきま
しょうか。これも、とくに tkdialog との違いをいっているということではあ
りません。new でダイアログが作成されるということであれば、インスタンス
をかえすことになりますからね  (new して popup ということはできるのだろ
うか)。とりあえず、tkdialog のように、メソッドから結果を得るというふう
に考えてよさそうです。

>そうですね．
>上に挙げたもの程度でいいのでしたら，
>もう少しインターフェースの設計をつめるだけで
>実作業に入れるのかもしれません．

おお!、頼もしいお言葉。

>ですが，例えば，「ファイル選択ダイアログ」のように，
>ちょっとした内部動作が必要なものはどう考えますか？
>こういうものも，この汎化されたダイアログから
>容易に作成できるようにすることを望まれているのでしょうか？

じつは、それも考慮に入っていたつもりです。容易かどうかはわかりませんが、
少なくとも、TkToplevel をつかうよりは簡単になることを期待しています。

>自前で作成したウィジェットを渡すと
>並べて表示してくれる程度のものなのか，それとも，
>表示するウィジェットの種類 (と表示文字列などの設定) を
>渡してやることでウィジェットの生成も含めて
>行ってくれるものなのか，というようなことも含めての議論ですね．

まだ僕の説明がよくなかったのかも。そういう管理装置 (?) ふうとか、 ダイ
アログ記述言語ふうではなくて、 TkToplevel をあつかうのと同じに考えてい
ました。ダイアログを書くのに適した性質をもった TkToplevel だというふう
に考えられると理想的だと思います。

とりあえず、 tkdialog の本質的なところを抜きだしたところでは、こんな感
じかなあと考えてみました。tk に関係して、 永井さん達に、よくわかってな
い僕がいろいろいうのも、なんかヘンな感じですよね。なんかトンデモナイ間
違いをおかしている気がする :-)

ところで、ウィジェットって子供を管理しているわけだから、ボタンが追加さ
れたとかいう場合に、それを知ることができてもよさそうですよね。そういう
のってできないのでしょうか。これができるとかなり賢いことできそう。それ
から、やっぱり、ダイアログの結果として、ボタンの番号を得られるよりも、
command で、proc を実行してくれたほうが汎用性があっていい感じに思える
んですが、これはどう思いますか?

--Tadayoshi Funaba