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-18 10:03:00 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!cyclone.bc.net!newsfeed.media.kyoto-u.ac.jp!feed.cgocable.net!read2.cgocable.net.POSTED!53ab2750!not-for-mail Message-ID: <3E527506.6070209@cogeco.ca> From: "Warren W. Gay VE3WWG" User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 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> <3E5121BD.4010200@cogeco.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 18 Feb 2003 13:01:42 -0500 NNTP-Posting-Host: 24.150.168.167 X-Complaints-To: abuse@cogeco.ca X-Trace: read2.cgocable.net 1045591329 24.150.168.167 (Tue, 18 Feb 2003 13:02:09 EST) NNTP-Posting-Date: Tue, 18 Feb 2003 13:02:09 EST Organization: Cogeco Cable Xref: archiver1.google.com comp.lang.ada:34205 Date: 2003-02-18T13:01:42-05:00 List-Id: Marin David Condic wrote: > You could get it down to one task if you basically go to some kind of > message protocol. Build a wrapper around something like GtkAda that deals > with the callbacks, etc. That builds up messages that are queued for the > app. The app pulls them out of the queue as it is ready for them and queues > up responses for the GUI. That doesn't fix Motif & GtkAda from being a C-ish > thing, but it hides all the C-ishness in the wrapper. You'd also get a means > by which you could have a portable GUI interface by building a similar > wrapper around Claw or anything else that gets dreampt up. But this still suffers from one problem: Each queue in your task would then have a monster case statement to split out the work according to the widget that is receiving the event. Compare this to the registered callback where only the interested widget for the event gets the callback. No big case statement required for event, or widget. Don't get me wrong.. I like the idea of queues and tasks. But this seems a clumsy thing beside a callback. > In the perfect world where there is an ongoing Ada Operating System project, > this might be a great design for the interface to the GUI. Asynchronous > message traffic via any number of communication mechanisms. > > MDC There may be a better model to use than a callback. I just don't seeing tasks, or tasks alone being it yet. If tasks are part of the solution, then you'd have to combine it with a Booch map (say) to eliminate those case statements, and to handle the dynamic creation and destruction of widgets that need to hook into events dynamically. But then after using a map, you might wind up in the end just doing a dispatch in callback fashion anyway.. ending up with the same end result. So I dunno.. I remain unconvinced. ;-) -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg