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=-0.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00 autolearn=no 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-22 06:11:34 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!feed1.newsreader.com!newsreader.com!beamish.news.atl.earthlink.net!guinness.news.atl.earthlink.net!news.atl.earthlink.net!stamper.news.atl.earthlink.net!harp.news.atl.earthlink.net!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada Subject: Re: [OT] Best way to isolate a GUI? (The final concensous?) Date: Sat, 22 Feb 2003 09:10:52 -0500 Organization: MindSpring Enterprises Message-ID: References: <3E511C15.1040404@acm.org> <3E5121BD.4010200@cogeco.ca> <3E51A55A.3000101@cogeco.ca> <3E52A1BF.1020809@cogeco.ca> <3E53CE60.1030008@cogeco.ca> <3E55501D.9050006@cogeco.ca> <3E5661F0.2060200@acm.org> NNTP-Posting-Host: d1.56.b0.88 X-Server-Date: 22 Feb 2003 14:11:34 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Xref: archiver1.google.com comp.lang.ada:34421 Date: 2003-02-22T14:11:34+00:00 List-Id: So here's a thing: Ada might potentially be able to evolve some sort of standard interface to the GUI world by saying "wrap up the GUI in something that will send and receive this set of messages". I'm curious what sort of mechanism might provide for a single thread or multiple threads (as you suggest, a task per window). Either you have the wrapper send things to a single queue, or you've got to have tasks defining queues and registering for events. I'm not sure that registering for events is such a bad thing - I've seen a number of OS-like things that have used this exact scheme and it works reasonably well. Certainly, if you go to a single queue, one could evolve yet another layer of abstraction on top of that which would allow for registration & multiple queues. Here's a problem though: You could use events/messages/etc or you could use procedure calls, callbacks, etc., but in either case you've got to have a lot of things carefully defined and you've got to limit yourself to the things that could be readily supported by most of the popular GUIs & GUI builders.Would you see this as a problem? I still like the message/event format because once you're hiding behind that skin the GUI could be in the next county and your app doesn't need to know, but I could see it involving quite a big message catalog & it doesn't get you around least-common-denominator problems. MDC -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/ Send Replies To: m c o n d i c @ a c m . o r g "Going cold turkey isn't as delicious as it sounds." -- H. Simpson ====================================================================== Jeffrey Carter wrote in message news:3E5661F0.2060200@acm.org... > > This is about what I was trying to say. I mentioned the idea of having a > task per window to emphasize the inherent concurrency of multiple > windows, and some posters seem to have fixated on tasks rather than on > the message (event) queue that was really what I was talking about. > > You can see an example of this, built on top of Windows, in JEWL. > Because it's intended for beginners, it's rather too simple for a > complete windowing system, but it does show how a GUI can be designed > using events ("commands" in JEWL parlance) rather than callbacks. It > doesn't prevent you from having dynamic windows or dialogs, nor does it > force you to use tasks. It does let you structure your system the way > you want, and control what it does, rather than structuring it for the > convenience of the windowing system, and giving control to that system. > This alone makes the software much easier to read and understand. >