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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,e429176c9adb07b X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-02-17 09:59:34 PST Message-ID: <3E5121BD.4010200@cogeco.ca> From: "Warren W. Gay VE3WWG" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: [OT] Best way to isolate a GUI? References: <3E511C15.1040404@acm.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 17 Feb 2003 12:54:05 -0500 NNTP-Posting-Host: 198.96.47.195 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1045504445 198.96.47.195 (Mon, 17 Feb 2003 12:54:05 EST) NNTP-Posting-Date: Mon, 17 Feb 2003 12:54:05 EST Organization: Bell Sympatico Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!nntp.cs.ubc.ca!torn!webster!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail Xref: archiver1.google.com comp.lang.ada:34173 Date: 2003-02-17T12:54:05-05:00 List-Id: Jeffrey Carter wrote: > Preben Randhol wrote: >> How do you connect callbacks? > > Callbacks are an excellent example of a tool's limitations affecting the > users' way of thinking (everything looking like a nail if you only have > a hammer). > ... > If one were to design a windowing system with thinking expanded by the > use of a language with high-level concurrency features (like, maybe, > Ada?), I can't imagine anyone choosing this design. I find that the "callback idea" works ok if you design it in a clean way (in Ada95 terms). I agree that the C method of hammering things from void pointers into client data and widget data, is ghastly at best. A generic could deal with the client data aspect. For input and output callback arguments, I use a discriminated record, which then allows Ada95 checks on record members according to the event type (ie. the record variation). This is something I wish GtkAda would use. > I would think you'd > want to associate a concurrent event queue for each window. A task in > the application would deal with the events for its window. It could > block on the queue to do nothing except respond to events, or it could > poll the queue periodically if it has other things to do as well. This sounds conceptually nice, but it could prove to have practical problems (I need to think about this more, myself). Thinking in terms of an X11/MOTIF application, where there can be hundreds of windows within windows to implement widgets on a form, this translates to hundreds (if not more) of tasks. This smells a lot like overkill upon first blush at least. Additionally, where the application wants access to one event, it would need to provide an entire task, and then have null handlers for all the events it was not interested in (I think). I think I'd need to prototype this to get a better feel for this. It might be easier to start with a tagged object, where methods can be inherited and overriden instead. That way all events can just do nothing, while you override the events you are interested in. But this takes us back to a model similar to callbacks anyways, but instead of registering a callback, you register a tagged record to receive callbacks. > While I like many things about GtkAda, one of the things I dislike about > it is that it hasn't abstracted away this C feature of the GUI. As a > result, it's harder to use tasking with GtkAda than it should be. CLAW > and JEWL, for example, have abstracted callbacks away to different > extents. JEWL effectively implements the concurrent event queue > abstraction on top of Windows. I can't speak for CLAW, and the one shortcoming I see in JEWL is that you cannot get "focus events". But the last time I played with GtkAda I didn't like the callback structures either. They were too prone to error, because of the data marshalling issues, IIRC. I would much rather that callbacks used discriminated records that matched the event type. Then everything compiles well, and is thoroughly checked, admitedly, some of it at run time. Most of all, the callback becomes a well documented interface, and is simple to code for and understand. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg