Re: [ruby-gnome2-devel-ja] Gtk::Window#set_geometry_hints

[Masao M. <mu...@hi...>]

むとうです。

On Sun, 06 Mar 2005 01:56:52 +0900
Chikara Takamatsu <c_t...@yb...> wrote:

> >高松さんは(1)の可能性のみに言及されていると思いますが
> >上のサンプルで(1),(2)を両方動かしてみて動きの違いを
> >見てください。
> >(1)の方ではWindow全体の最小値を指定していて、
> >(2)の方はCancelボタンの最小値を指定しているので
> >(2)の方がウインドウ全体として見ると小さくなりません。
> >
> 
> これで色々試してみたのですが(2)の場合の使う場面がよくわかりません。
> 例えばbutton1にジオメトリヒントを設定するとなんだか予想と一致しない結果
> になりますし
> button2の仕切りをドラッグすると最小以下になります（最小指定のメソッドが
> ありますが）。

それは、私の例がたまたまGtk::HPanedを使ってるからでしょう。
その辺はあくまでもLayout Managerに依存する部分かと。
＃Layout Managerとは簡単に言えば子ウィジェットを自分の中にどのように
＃配置するのか計算するウィジェット群です。

私の例は、あくまでもGdk::Geometryの効果がわかるように、かつ、window/widget
の違いを理解して頂くための例でした。

> button1とbutton2に同時にジオメトリヒントを設定することもできませんでした。
> ウィジェット別に、ウィンドウがリサイズした場合の挙動を変更できるのかと
> 思ったのですが…。

gtkwindow.cを読んで頂ければ解ると思うのですが、実はウインドウ１つにつき
１つしかGeometryを設定できません。

まぁ、こういう低レベルなAPIはそれがLayout Managerとどう影響し合うのか、
十分理解した上で使うものかと。簡単に言えばCでWidgetを作る人向けといいますか。

> >Gdk::Geometryの各デフォルト値はどうするべきでしょうか？
> >例えば、min_sizeにとってmin_size.max_sizeの結果は0でしょうか。
> >それとも-1？
> >＃今は特に初期化していなくて不定なので、変な値が返りますね。
> >＃実用上は問題ないですけど、これは直さないといけないかな。
> >
> >
> >>geometry = min_size | max_size | resize_inc # or min_size + max_size +
> >>resize_inc
> >
> >
> >そして、この計算をしたときに、それらのデフォルト値は
> >どう計算するのでしょうか？
> >
> >そういう、曖昧な部分をなくすためにもmaskがあるのは
> >有効だと思います。まぁ、ポリシーの違いと言えばそれまでですが。
> >
> >また、maskを使えば、１つのGdk::Geometryで複数の表現を
> >することができます。
> >＃その使い方を推奨するわけではありませんが。
> 
> ええと、自分の考えでは不完全なGdk::Geometryをでっち上げて
> 既存ウィンドウが使っていたであろうGdk::Geometryに上書きするイメージでした。
> まずGeometry.newで各デフォルト値をfalseとして初期化し、|や+を
> どちらかが真→真の値にする
> 共に偽→偽のまま
> どちらも真→変数の種類によって採る値を分ける
> （min_sizeなら1以上の小さい方の値、max_sizeなら1以上の大きい方の値...）
> とします。

そもそもmin_sizeという数値が入るべき値にtrue/falseの概念を
持ち込むのはあまり私の好みではありません。min_size/max_sizeは0も取り得る
でしょうし。
それから、その考えはこのメソッドに限れば有効ですが、他にGdk::Geometryを
使うような場面で有効かどうかというとかなり疑問です。
Gdk::Geometryをこのメソッド専用の引数を作るためのクラス、という
位置づけにしてしまっているように見受けられますが、元々、Gdk::Geometry
はそれ自身がジオメトリ情報を扱うクラスです。

> そしてGdk::Geometryに偽でなければ上書きするインスタンスメソッドを作って
> set_geometry_hints内で
> window_geometry.merge(user_geometry)
> こんな感じに呼ぶと。
> 
> 元となるウィンドウのジオメトリが曖昧さをカバーする…ハズです（自信無し）。
>
> 利点はもしGdk::Geometryに何か変数が増えた場合にも
> 変更がクラス内だけで済むだろうということ
> そして、ユーザーがmaskを考えなくてもいい（適当にGeometryを設定して渡せば
> いい）
> ということです。

Gdk::Geometryに変数が増えた場合（って増えないと思いますが）
maskを使う場合でも問題ないと思いますが...。

> 普通変更する部分しか設定しないでしょうから…。

それはたまたま先ほどのwindow/widgetの時と同じように
そのような使い方を(限定して)想定してしまっている、という話だと
思いますよ。
どこからか取得したGdk::Geometryを使って云々、ということをするかも
しれないですし。

> 何度もしつこくてすいません。
> 
> # 何だか自分がどんどん間違っていってる気もする

一応、整理しますと、

・現時点のAPIが正しいかどうか
　→機能を満たしているという意味ではYes

というのが私の回答で、それは認識していただけたと思っています。

次に、その後の改善策として、maskを使わないでも済む案を
提案していただいているのだと思いますが、
残念ながら、現時点では、ユーザがmaskを認識する方が確実、
というのが私の認識です。

-- 
.:% Masao Mutoh<mu...@hi...>