# Type\_register does not override default signal handler when the handler is included

**URL:** <https://www.ruby-forum.com/t/type-register-does-not-override-default-signal-handler-when-the-handler-is-included/160565>\
**Category:** Ruby-Gnome 2\
**Created:** [February 17, 2009, 7:16pm UTC](https://www.ruby-forum.com/t/type-register-does-not-override-default-signal-handler-when-the-handler-is-included/160565 "2009-02-17T19:16:53Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Kentaro\_F](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/c89c15/32.png) [@Kentaro\_F](https://www.ruby-forum.com/u/Kentaro_F)\
**Post date:** [February 17, 2009, 7:16pm UTC](https://www.ruby-forum.com/t/type-register-does-not-override-default-signal-handler-when-the-handler-is-included/160565/1 "2009-02-17T19:16:53Z")

</div>

Hi all,

When you want to override a default signal handler in your new class  
widget,  
calling type\_register is the best and only way in the current ruby-gtk2.

class MyLabel \< Gtk::Label  
type\_register  
def signal\_do\_expose\_event(e)  
…  
end  
end

Ruby-gtk2 finds the newly defined signal handler by wathcing method  
definitions  
by using ‘method\_added’. However, it does not work if a signal handler  
is defined  
in a module and the class included it.

module NiceBehaviour  
def signal\_do\_expose\_event(e)  
…  
end  
end

class NiceLabel \< Gtk::Label  
type\_register  
include NiceBehaviour  
end

I attached a working sample to this message. Run it and resize the  
window.

Is there any nice trick to avoid this problem? Or should we add a new  
method  
to Ruby-gtk2? (just like the old signal\_override()?)

Kentaro F.

---

<div class="post-metadata">

**Author:** ![Kentaro\_F](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/c89c15/32.png) [@Kentaro\_F](https://www.ruby-forum.com/u/Kentaro_F)\
**Post date:** [February 20, 2009, 2:25pm UTC](https://www.ruby-forum.com/t/type-register-does-not-override-default-signal-handler-when-the-handler-is-included/160565/2 "2009-02-20T14:25:07Z")

</div>

Hi,

In [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
“[ruby-gnome2-devel-en] type\_register does not override default signal  
handler when the handler is included” on Wed, 18 Feb 2009 02:57:56  
+0900,  
Kentaro F. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> class NiceLabel \< Gtk::Label  
> type\_register  
> include NiceBehaviour  
> end
> 
> I attached a working sample to this message. Run it and resize the window.
> 
> Is there any nice trick to avoid this problem? Or should we add a new method  
> to Ruby-gtk2? (just like the old signal\_override()?)

There is no workaround for the problem. You need to define  
callback method in your class. We should fix the problem in  
the next release.

# You can also use ruby-gnome2-devel-ja. 😉

## Thanks,

kou

---

<div class="post-metadata">

**Author:** ![Kentaro\_F](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/c89c15/32.png) [@Kentaro\_F](https://www.ruby-forum.com/u/Kentaro_F)\
**Post date:** [February 22, 2009, 9:49am UTC](https://www.ruby-forum.com/t/type-register-does-not-override-default-signal-handler-when-the-handler-is-included/160565/3 "2009-02-22T09:49:49Z")

</div>

Hi,

From: Kouhei S. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
Date: Fri, 20 Feb 2009 22:24:25 +0900 (JST)

> Hi,
> 
> In [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
> “[ruby-gnome2-devel-en] type\_register does not override default signal handler when the handler is included” on Wed, 18 Feb 2009 02:57:56 +0900,  
> Kentaro F. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:
> 
> > Ruby-gtk2 finds the newly defined signal handler by wathcing method definitions  
> > by using ‘method\_added’. However, it does not work if a signal handler is defined  
> > in a module and the class included it.

> > Is there any nice trick to avoid this problem? Or should we add a new method  
> > to Ruby-gtk2? (just like the old signal\_override()?)
> 
> There is no workaround for the problem. You need to define  
> callback method in your class. We should fix the problem in  
> the next release.

Fixing the problem may be difficult.

If #signal\_do\_expose is defined in the class C, Ruby-gtk2 includes in  
C a corresponding module (say M) having #signal\_do\_expose. Then  
“super” in C#signal\_do\_expose invokes M#signal\_do\_expose and it calls  
g\_signal\_chain\_from\_overridden() to chain up to parent handlers in GTK  
side.

But if #signal\_do\_expose is defined in a module M2 this trick does not  
work, since relative ordering of M and M2 in C’s inheritance hierarchy  
is indeterminate.

To be honest, I regret that I adopted such a tricky mechanism, and  
now I think that the old signal\_override() was a right way…

Regards,

– Masahiro S.

---

<div class="post-metadata">

**Author:** ![Kentaro\_F](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/c89c15/32.png) [@Kentaro\_F](https://www.ruby-forum.com/u/Kentaro_F)\
**Post date:** [February 25, 2009, 4:23am UTC](https://www.ruby-forum.com/t/type-register-does-not-override-default-signal-handler-when-the-handler-is-included/160565/4 "2009-02-25T04:23:11Z")

</div>

On Sun, 22 Feb 2009 17:30:53 +0900 (JST)  
Masahiro S. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> is indeterminate.  
> One possible option is overriding Class#include method in type\_register.

class Class  
def include (\*args)  
super  
args.each {|mod|  
mod.instance\_methods.each {|method|  
if method.match (/^signal\_do\_/)  
…  
end  
}  
}  
end  
end

Even if two or more modules are included, it would be possible to  
override signal handlers in the order the user expected.

> To be honest, I regret that I adopted such a tricky mechanism, and  
> now I think that the old signal\_override() was a right way…

“Convention over configuration” is not so bad. However there still be  
a complicated fault in above trick when signal handlers are added to  
a module AFTER it is included. To avoid all of this kind of fault,  
we have to hook all signal calls of GObject and it causes serious  
performance loss.

Is it able to provide BOTH of them, automagical overriding of  
signal\_do\_\*  
and signal\_override()? Most developers are happy with signal\_do\_\*, and  
some hackers are allowed to explore the limitation of the library with  
signal\_override().

Kentaro