Re: [gtk-list] Emitted signals




Ian Main <slow@intergate.bc.ca> writes:

> I have just written up the following section for the tutorial, and am
> wondering just how far from the truth I really am :)
> 
> Anyone care to comment please ?

> <sect1>Widget Signals
> <p>
> And here is a complete (?) list of all the signals gtk has, and which
> signals are emitted by various widgets.  Any signals emitted by widgets
> higher in the hierarchy are inhereted.

Probably correct - I'm not really sure that this type of information
is all that useful in a tutorial - it's probably best left to
reference documentation. Some of these signals are really more
"virtual functions" that only are of interest for widget
implementation. It's probably more important to point out the
_important_ signals for each type of widget and give some explanation.

We do seem to be heading toward adding some reference material to the
the "tutorial" - some of which can be justified on the basis of giving
an overview, some of which can be justified because it is important
information that people need to know, and isn't present elsewhere.

The complete list of signals seems to be a bit undigestible though,
because of the need to cross reference with the widget heirarchy,
and might be better presented in chunks with irrelevant signals
omitted... 

> 
> </verb></tscreen>
> <p>
> The following are emitted by any widget with an associated X window.
> 
> <tscreen><verb>
> "show", "hide", "map", "unmap", "realize", "unrealize", "draw", "draw_focus",
> "draw_default", "size_request", "size_allocate", "state_changed", "install_accelerator",
> "remove_accelerator", "event", "button_press_event", "button_release_event",
> "motion_notify_event", "delete_event", "destroy_event", "expose_event",
> "key_press_event", "key_release_event", "enter_notify_event", "leave_notify_event",
> "configure_event", "focus_in_event", "focus_out_event", "map_event",
> "unmap_event", "property_notify_event", "selection_clear_event",
> "selection_request_event", "selection_notify_event", "proximity_in_event",
> "proximity_out_event", "other_event", "move_resize".
> </verb></tscreen>

Actually, quite a few of these can occur even without an associated X
window. I think just the "event" signals need a window (except for the
expose_event which is an exception. Just to give an example, of what I
was saying above, of these signals, I can't think of any reason why
a user needs to know about

  draw, draw_focus, draw_default, size_request

and 

  show, hide, map, unmap, realize, unrealize,
  install/remove_accelerator, size_allocate, move_resize

are primarily virtual functions, but could conceivably have user
functions attached to them to advantage. (Of course, the
widget-writing portion is coming along - but I don't think it's good to
confuse the beginner to help those who are more advanced.)

But a comprehensive list is probably than no list, so maybe you should
include it, until there's enough detail for each widget to let people
know which signals they _should_ care about.

Regards,
                                        Owen



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]