From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,37023471dc2e1934 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!wns13feed!worldnet.att.net!208.49.83.146!atl-c08.usenetserver.com!news.usenetserver.com!pc02.usenetserver.com!news.flashnewsgroups.com-b7.4zTQh5tI3A!not-for-mail Newsgroups: comp.lang.ada Subject: Re: Custom model in gtkada? References: <3ndpd7br1nn9$.vkcrts8e898z.dlg@40tude.net> <20060614210028.GA18024@ws.max.zp.ua> <44917d39$0$4495$9b4e6d93@newsread2.arcor-online.net> <44941be9$0$11065$9b4e6d93@newsread4.arcor-online.net> <14e2r2ftir9ok.i8u1axnplx11.dlg@40tude.net> <449a432e$0$15869$bb6a4dc3@news.uunet.fr> From: Stephen Leake Date: Fri, 30 Jun 2006 12:07:24 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (windows-nt) Cancel-Lock: sha1:dIKN7bNeOjVhvuzIZYFZzaxfMPU= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: abuse@flashnewsgroups.com Organization: FlashNewsgroups.com X-Trace: 2b8c144a54c4d63d2959b30254 Xref: g2news2.google.com comp.lang.ada:5344 Date: 2006-06-30T12:07:24-04:00 List-Id: "Jeffrey R. Carter" 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