Re: Custom model in gtkada?

[Stephen Leake <Stephe.Leake@nasa.gov>]

"Jeffrey R. Carter" <spam.not.jrcarter@acm.not.spam.org> writes:

> 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. 

In that case, the GUI is in one thread, and the "backend" is in
another (or more).

> 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".

Well, that's a poorly designed _system_. It has nothing to do with the
GUI design.

Hmm. The GUI has to allow communicating with the background thread.
But that's more of a language or communications package issue.

>> I'm not sure what you mean by "locality" here.
>
> Locality is a basic SW-engineering principle. You should be familiar
> with it. 

I'm familiar with several definitions; I'm wondering which one you are
talking about.

> 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.

Ok, you are talking about source code "locality".

In an Ada GUI, the _spec_ for a callback is located in the same
package as the widget that provides the hook for the callback. Is that
no "local"? Obviously, the _body_ for the callback is provided by the
user.

How could it be otherwise, if a GUI is to provide a user-customizable
framework?

>> 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.

Ok. In that case, the window object needs to contain pointers to the
full state. Still no global variables.

>> 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. 

Ok, you are using a jargon definition of "intuitive". It still means
"familiar"; ie, "something I learned before".

> People grasp it easily; it corresponds to their understanding of how
> active entities function in the world. 

you mean "in computer programs they have used before". It is _not_ how
things work in the real world; physics and engineering is a better
model for that.

> The callback model is more difficult to understand because it's not
> intuitive.

Once you have grasped it, it is no more difficult.

>> 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. 

Ok, I misunderstood.

> 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.

Ok; the concurrency must be designed for the application. That's what
I've been saying.

> 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. 

Now I'm confused. "event queue" is orthogonal to "callback", as far as
I can tell. The windowing systems I use have both event queues (to
store and serialize the events) and callbacks (to handle the events).

> 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. 

I think you mean the event queue was more visible in JEWL. CLAW has an
event queue (because MS Windows does), but it's not visible to the
client packages.

> This is in part because JEWL is a simple windowing library, without
> the power and complexity of more complete systems. 

Yes.

> But it's also in part because, despite my familiarity with callback
> libraries, the event-queue model is simpler and more intuitive.

Not to me :).

> 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.

That is a reasonable request, but I don't have the time.

-- 
-- Stephe