Re: Custom model in gtkada?

["Jeffrey R. Carter" <spam.not.jrcarter@acm.not.spam.org>]

Stephen Leake wrote:
> 
> I disagree. I only click on one thing at a time.

What is your program doing when you click? The concurrency comes from 
programs needing to do something else and respond to user events at the 
same time, which is a fairly common situation. That's easy to do with a 
concurrent language and a GUI library designed for concurrency. With a 
sequential language and sequential thinking, you get the typical C-style 
callback design, in which the GUI takes over the single thread of 
control, and you get other things to happen when you're not responding 
to user events through "idle functions".

> I'm not sure what you mean by "locality" here.

Locality is a basic SW-engineering principle. You should be familiar 
with it. It basically says that everything specific to understanding 
something should be located together. You should only have to look at 
one package spec to understand all the operations of a type declared in 
that spec, for example.

> Not in a well designed GUI framework; the window object is a parameter
> to the callback; no globals.

The window object is not the state of the program. Knowing how the 
previous event with widget X affects the program's response to this 
event with widget Y is the state.

> You simply mean "unfamiliar". That is a function of time spent learning.

No, I mean "intuitive". The standard imperative program model, in which 
the program is in control, and which almost everyone learns 1st, is 
intuitive. People grasp it easily; it corresponds to their understanding 
of how active entities function in the world. The callback model is more 
difficult to understand because it's not intuitive.

> You are saying "each window should have its own thread of control".
> That's way overkill.

No, I'm saying each window may have its own thread of control. For many 
programs, a single thread of control is sufficient. For others, there 
may be a need to update each window continuously. In such a case, each 
window having its own task is not overkill.

In the mid-1980s I considered how to implement a windowing system in 
Ada, and decided event queues were the simplest and clearest approach. I 
then used actual windowing systems, with callbacks, and saw nothing to 
change my mind. I've used CLAW, which uses type extension and 
overriding. When I used JEWL, which has an event queue, it was much 
easier to use. This is in part because JEWL is a simple windowing 
library, without the power and complexity of more complete systems. But 
it's also in part because, despite my familiarity with callback 
libraries, the event-queue model is simpler and more intuitive.

Don't take my word for it, though. Implement a few (not-too) simple 
using JEWL and your callback library of choice, and see what you think.

-- 
Jeff Carter
"I unclog my nose towards you."
Monty Python & the Holy Grail
11