Re: Custom model in gtkada?

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
.

Relevant Pages

  • Re: Custom model in gtkada?
    ... I think neither callbacks nor dispatching are good models. ... Not in a well designed GUI framework; the window object is a parameter ... with a way to control what events are reported. ... without analyzing the true concurrency. ...
    (comp.lang.ada)
  • Re: Matlab GUI newbye
    ... code AFTER you right click on the control then select "View Callbacks" ... the callback function actually show up in the source code. ... Plus there's no way to dock the properties window. ...
    (comp.soft-sys.matlab)
  • Re: Matlab GUI newbye
    ... code AFTER you right click on the control then select "View Callbacks" ... the callback function actually show up in the source code. ... it brings up the properties window instead of the ... CreateFcn() function for that control doesn't have any code in it, ...
    (comp.soft-sys.matlab)
  • Re: Control.BeginInvoke
    ... How do I create a window in my .NET class (not derived from control, ... In C++ I would just call Create Window and specify a win proc callback. ...
    (microsoft.public.dotnet.framework.windowsforms.controls)