Re: signal help (loop)

[Havoc Pennington <hp redhat com>]

Guillaume Bellue <guillaume-b wanadoo fr> writes:
> I got a loop problem with signals... the problem is that
> gtk_widget_queue_draw() emits an "expose_event". Can't i use
> gtk_widget_queue_draw() in the "expose_event" handler ?
>
> here's what i did, but it seems it doesn't prevent the function to
> loop...
> what am i doing wrong ?
>
> void 
> expose_event_handler (GtkWidget *zoneimage)
> {
>    gdk_draw_gray_image (zoneimage->window,
>                      gdk_gc_new(zoneimage->window),
>                      0,0, SIZE, SIZE,
>                      GDK_RGB_DITHER_NORMAL,
>                      image,
>                      SIZE);
>
>    gtk_signal_handler_block_by_func (GTK_OBJECT (zoneimage),
>                                   GTK_SIGNAL_FUNC (expose_event_handler),
>                                   NULL);
>    gtk_widget_queue_draw (zoneimage);
>    gtk_signal_handler_unblock_by_func (GTK_OBJECT (zoneimage),
>                                     GTK_SIGNAL_FUNC (expose_event_handler),
>                                     NULL);
>    gtk_signal_emit_stop_by_name (GTK_OBJECT (zoneimage),
> "expose_event");
> }

Your block/unblock there doesn't work because queue_draw() is
asynchronous, it queues a draw to be done later. So the handler is
unblocked when the draw actually happens.

The usual way of doing this is to simply write a separate function, 
foo_paint(), that both the expose handler and the draw handler will
call. That shares the code and avoids loop problems.

In GTK 2, the "draw" signal has simply been removed, there's only
expose. Because it never made sense to have two signals that both had
to be handled by doing a redraw. So gtk_widget_queue_draw() in GTK 2
actually queues an expose.

GtkDrawingArea in GTK 1.2 works that way in essence, its draw handler
generates an expose_event, so you only have to handle
expose_event. All GTK 2 widgets work this way now.

Havoc