師星です。

> >>> ただ、個別のwidgetでばらばらにsignal handlerをconnectしてしまうことにな
> >>> る点については、他の方のご指導を頂きたいところです。
> >>>
> >>signal_connect_afterの方が良いんでないでしょうか?
> 
> 	添付のパッチの方針で対応可能ではあると思いますが、Ruby側で
> 	同じsignalに体するsignal handlerの上書きを行った場合にどう
> 	するかという問題があると思います。
> 	そういう意味ではsignal_connect_afterの方が良いかと思います。
> 
> #一番良いのはfinalizerの方ですが

確かに。signal_connect_afterの方が良いですね。
GTK+にfinalizerを持たせる仕組みがある(?)のは不勉強にして知りませんでした。

そうすると、rbgtk.cのset_object()も同様に変更して頂くのがよいのでしょうか。

--- rbgtk.c.orig	Wed Oct 11 20:04:18 2000
+++ rbgtk.c	Sun Oct 22 22:28:37 2000
@@ -186,7 +186,7 @@
     rb_ivar_set(obj, id_relatives, Qnil);
 
     rb_ivar_set(obj, id_gtkdata, data);
-    gtk_signal_connect(gtkobj, "destroy",
+    gtk_signal_connect_after(gtkobj, "destroy",
 		       (GtkSignalFunc)delete_gobject, (gpointer)obj);
     st_add_direct(gtk_object_list, (char*)obj, (char*)obj);
 }

> 	それと今回は、Gtk::CListで出た訳ですが、他のクラスでも同様の
> 	問題が起こり兼ねないので基本クラスで仕掛ける方が良いかも。

うぬぬ、私もそう思ったのですが、GTK+、Ruby/GTK両者にあまり詳しくないこと
もあり、すぐにはうまい仕掛けどころが見つからなかったのでした。

> 	それと、ちょっと話は変わるのですが、Ruby/GTKのスナップショット
> 	版へのリンクと、今回のパッチをウチのWebPageに載せたいのですが
> 	構いませんか? > 五十嵐さん&師星さん

はい、私のパッチに関しては全然構いません。
# gtk_signal_connectは同_afterにして下さい

 - moro.