Re: Custom model in gtkada?

"Jeffrey R. Carter" <spam.not.jrcarter@xxxxxxxxxxxxxxxx> 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
.

Relevant Pages

  • Re: How to change JPanels?
    ... You are the programmer. ... If you run slow things on the EDT, you will have a slow GUI. ... Windows has a single event queue, ... user a new window, a new button on the window, and a menu option on ...
    (comp.lang.java.help)
  • Re: GUI question
    ... I want to make a GUI based, which contains a main GUI and ... It is possible to do this using a modal window. ... issue the command within the first windows's callback (when ...
    (comp.soft-sys.matlab)
  • Re: How to change JPanels?
    ... You are the programmer. ... If you run slow things on the EDT, you will have a slow GUI. ... Windows has a single event queue, ... user a new window, a new button on the window, and a menu option on ...
    (comp.lang.java.help)
  • Avoid main GUI fig to close
    ... I've got some problems with my "new" GUI. ... grateful if some of you can help me. ... The callback of a Pushbutton executes some code which uses ... problem is that when it's finished, the main window ...
    (comp.soft-sys.matlab)
  • GUI problem in callback
    ... I am now designing a GUI. ... I input the parameter in my GUI, then it have a Callback at the Fuzzy ... And i want the "view rule" window of the fuzzy logic GUI would ...
    (comp.soft-sys.matlab)