@toshi_a
GtkMenu.deactivateをgtk_widget_destroyにconnectしてるとあかんな
これを外した状態でメニュークリックまでのsignal眺めてたら
GtkMenuItem.select
GtkMenuItem.deselect
GtkMenuItem.activate
GtkMenuShell.selection-done
の順で発火された。
@shibafu528 destroy signalのブロックの戻り値falseになってる?
@toshi_a no, destroyは購読してない
@shibafu528
> GtkMenu.deactivateを
> gtk_widget_destroyにconnectしてるとあかんな
これどういうこと
@toshi_a
menu.ssc(:deactivate) { menu.destroy }
言われてあれっ?となったんですが、gtk_widget_destroyしたらそりゃ何もできずに死ぬ気がするな。
これは単にmikutter/gtk3の実装バグかもしれん。
@toshi_a これの場合はactivateのハンドラーに到達しないね。deactivateが先に実行されて終了。
@shibafu528 destroyされたGtkWidgetにも普通にsignal_emitできるから関係ないと思うんだけど、これはgtk2の知識なので、mikutterのバグと断定してよさそう。そのほうが楽よね
@toshi_a そうだね、一旦それで進めたほうが動かせる範囲が広がるので前進できそう。
@toshi_a ちなみにsignal_connectのブロック戻り値ってどういう意味になってる?
Valadocでいうout引数がある場合に対応してる程度に思ってるんだけど、ruby-gnomeにおいては何か意味付けされてる?
@shibafu528 gtk2では、真を返すとイベントチェーンが止まる。要するにpreventDefault()みたいなやつ。
@shibafu528 ブロックの最後にfalseって書きまくってるのはそういうことです…(たまにハマッてつらい)