recent GSignal block/disconnect variants
- From: Tim Janik <timj gtk org>
- To: Gtk+ Developers <gtk-devel-list gnome org>
- Cc: Owen Taylor <otaylor gtk org>, Havoc Pennington <hp redhat com>, Alexander Larsson <alla lysator liu se>
- Subject: recent GSignal block/disconnect variants
- Date: Sun, 27 May 2001 18:47:08 +0200 (CEST)
hey owen, havoc, alex,
acoording to one of our irc meetings, we now have
the convenience variants:
g_signal_disconnect_by_func()
g_signal_block_by_func()
g_signal_unblock_by_func()
while the regular API is:
g_signal_handler_block()
g_signal_handlers_block_matched()
g_signal_handler_disconnect()
the GSignal API is intended to make obvious the distinction
between "signals" and "handlers", something many users
are confused about.
people talk about "blocking signals", "emitting handlers",
"stopping handlers" and so on, though the correct terminology
(dictated by the concepts involved) which needs to be reflected
by the GSignal API is:
* connecting (a handler) to a signal
* blocking a signal handler
* emitting a signal
* stopping (intercepting) a signal emission
i'm sorry for not catching this earlier, but the prototypes
need to be renamed to (honouring that owen wants the
"_by_" parts in the function names):
g_signal_handlers_disconnect_by_func()
g_signal_handlers_block_by_func()
g_signal_handlers_unblock_by_func()
alternatively we can have the shorter variants (though
it doesn't meet owens need for the "_by_" part and doesn't
reflect that possibly >1 handlers are affected):
g_signal_disconnect_func()
g_signal_block_func()
g_signal_unblock_func()
because its the handlers (func) that an operation
is being performed on here.
i'm indifferent on which version we pick, however
g_signal_block_by_func() is definitely misleading and needs
to be fixed, because its not a signal that's being blocked here.
---
ciaoTJ
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]