Re: Stoppers for IUP..? (Re: GTK Binding)

[Clemens Wacha <clemens.wacha@...>]

Am Son, den 29.02.2004 schrieb Jay Carlson um 01:01:
> Mark Stroetzel Glasberg wrote:
> 
> >>guiinit = loadlib("./guilib.a", "init")
> >>guiinit()
> > 
> > 
> > Looks simple enough. Shouldn't be hard to do that with LoadLibrary.
> > You need to call IupOpen() and iuplua_open(lua_State*).
> 
> The problem is when to start running the GUI event loop, especially if 
> you want to keep your original console interactive...

This is a problem in general. I wondered how tcl/tk solved this because
I couldn't remember thinking about this problem when i used tcl/tk. The
trick they use is that they start with an initial window in a seperate
thread. So if you start the event loop it returns immediately.

This gives you another big problem. If you want to work with shared data
between those 2 threads you will need semaphors and before that you will
have to understand how they work... :-)

The classical approach is nice for coders like me but not so good for
beginners.
1. gui_loop() starts the event loop and only returns if you destroy all
windows.
2. gui_processevents() returns after drawing the window stuff. This
function has to be called in the users own loop over and over again. The
problem here is that if you don't call it, your windows won't get
updated. If you wait for a network connection your application hangs
until connect/timeout. 

Both approaches are bad because none of them produces good code if we
don't FORCE the users to read the documentation. And we need clean and
simple examples in the docs to explain how to handle those "problems".

Personally I vote for the first approach with an extra thread for the
gui. Actually there is nothing that could prevent us providing a third
function called gui_thread() that creates a thread for the windows and
returns immediately.

Regards
-- 
Clemens Wacha           wacha@gmx.ch           ICQ:12620942

proudly running Debian/GNU Linux. See http://www.debian.org