Re: [OT] Best way to isolate a GUI?

[Jeffrey Carter <jrcarter@acm.org>]

Preben Randhol wrote:
> 
> How do you connect callbacks?

Callbacks are an excellent example of a tool's limitations affecting the 
users' way of thinking (everything looking like a nail if you only have 
a hammer).

Windowing systems result in inherently concurrent processing: the code 
of the windowing system may be dealing with user interaction while the 
application program is doing something else. How do you deal with this 
concurrency? When your thinking is constrained by the limitiations of C, 
you do it by task inversion: You eliminate the concurrency. Only the 
windowing code is running; application code is called by the windowing 
code. How can the windowing code call the application? By having the 
application register callbacks with the windowing system before handing 
control of the program over to the windowing system. In C, where nothing 
is checked and you can call any address, this is easy to do.

If one were to design a windowing system with thinking expanded by the 
use of a language with high-level concurrency features (like, maybe, 
Ada?), I can't imagine anyone choosing this design. I would think you'd 
want to associate a concurrent event queue for each window. A task in 
the application would deal with the events for its window. It could 
block on the queue to do nothing except respond to events, or it could 
poll the queue periodically if it has other things to do as well.

While I like many things about GtkAda, one of the things I dislike about 
it is that it hasn't abstracted away this C feature of the GUI. As a 
result, it's harder to use tasking with GtkAda than it should be. CLAW 
and JEWL, for example, have abstracted callbacks away to different 
extents. JEWL effectively implements the concurrent event queue 
abstraction on top of Windows.

-- 
Jeff Carter
"Why don't you bore a hole in yourself and let the sap run out?"
Horse Feathers