Date: Thu, 3 May 2001 09:04:07 +0200
From: Nicolas GEORGE <nicolas.george at ens.fr>
To: Jeff Henrikson <jehenrik at yahoo.com>
Cc: lablgtk at kaba.or.jp
Subject: Re: lablgtk bugs
Message-ID: <20010503090407.A18020 at clipper.ens.fr>
References: <001c01c0d390$742c8540$4d4106d1 at mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <001c01c0d390$742c8540$4d4106d1 at mit.edu>; from jehenrik at yahoo.com on Thu, May 03, 2001 at 01:18:14AM -0400

Le quartidi 14 floréal, an CCIX, Jeff Henrikson a écrit :
> 2) Is there a way to repaint a window in a multithreaded app from a
> non-drawing thread?  It seems that most of the examples just call their
> own paint handlers directly.

Yes, it is quite common.

>				This is bad when you have multiple theads
> because to get your drawing right it's best to have only one thread
> drawing.

Right. More : Gdk doesn't allow to use graphics primitives in more than
one thread. Note that if you are using bytecode version without system
threads, this is not a problem ; but you can not rely on that.

>	    The ordinary way to deal with this is to send an expose message
> to yourself when you want to paint.

I disagree.

>					But I can't figure out how to use
> any of the "emit" functions in gtkSignal.ml or anywhere else:

You should not use them : there are private. There are reserved for
widgets implementors. What you want here is to use

	GtkBast.Widget.queue_redraw

Then your widget will get a "draw" signal. More : Gtk will wait until it
is less loaded, and will send only one such signal, event if you queue
several before they are processed.