RFC: refactoring window-register as widget-register + containing window

[Josh Sled]

On Thu, Nov 22, 2001 at 03:14:19PM -0800, Josh Sled wrote:

| Handling Actions
| ----------------
[deletia]
| These signals will be attached-to by default handlers [provided by the
| widget-register]... however, these default signal-handlers will be set to be
| handled last, iff any later-attached signal handlers allow them to run [via
| return status].

Well, investigation reveals that GTK only supports this behavior for
parent-handling... to determine when the child has handled the signal
and the parent doesn't need to... it doesn't support this for a chain of
signal-handlers, or for the chain of user-defined signal-handlers vs. the
default handler.

As well, I learned that "default handler" has a specific meaning GTK,
which is a specific function which is invoked in a certain relation to
the user-defined callback/signal-handler list... I want to clarify that
when I mean "default handler" I'm referring to a normal "user-defined"
signal handler which is attached by default to the widget-register's
signal-handling for signals it emits.

[ as in:
  gtk_signal_connect( button, "clicked", clicked_a );
  gtk_signal_connect( button, "clicked", clicked_b );
  with clicked_a returning TRUE doesn't prevent clicked_b
  from running... but would prevent "clicked" from being
  passed on to the ToggleButton which Button is based on; see
  http://mail.gnome.org/archives/gtk-list/1998-June/msg00730.html, or the
  GTK FAQ topic.  Apparently, GTK 2.0 solves this [any signal-handler which
  returns TRUE stops the current emission and all subsequent emissions]. ]

So, there are a couple of options:

. Document that callers of the GNCRegWidget would need to call
  gtk_signal_stop_emit_by_name( regWidget, "foo_signal" ) [if desired]
  in order to prevent the "default" handler from being invoked.

. Make all signal attachment explicit; callers would be required to
  connect the non-file-static provided/"default" signal handlers from
  gnc-register-widget.[hc] to the signals.

I'm kind of leading toward the former, because it makes life easier for
the callers...

In other thoughts, I'm leaning toward a "positive" functionality vector,
as new functionality provided by later iterations of the widget-register
may not have sane default behavior for all callers ... best to be explicit
about what is desired to happen rather than be vague about what shouldn't
happen ].

...jsled