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 17:39:00 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!nntp.cs.ubc.ca!nntp-relay.ihug.net!ihug.co.nz!west.cox.net!cox.net!newsfeed1.earthlink.net!newsfeed.earthlink.net!stamper.news.pas.earthlink.net!newsread1.prod.itd.earthlink.net.POSTED!not-for-mail Message-ID: <3E518EA0.1080702@acm.org> From: Jeffrey Carter User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.0) Gecko/20020530 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 01:37:25 GMT NNTP-Posting-Host: 63.184.8.187 X-Complaints-To: abuse@earthlink.net X-Trace: newsread1.prod.itd.earthlink.net 1045532245 63.184.8.187 (Mon, 17 Feb 2003 17:37:25 PST) NNTP-Posting-Date: Mon, 17 Feb 2003 17:37:25 PST Organization: EarthLink Inc. -- http://www.EarthLink.net Xref: archiver1.google.com comp.lang.ada:34183 Date: 2003-02-18T01:37:25+00:00 List-Id: Warren W. Gay VE3WWG wrote: > > 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. I wouldn't think you'd want a queue for every widget. I'd think one per top-level window would be about right. The events in the queue would have to identify the widget that generated them. In some cases you'd have a task for every window, while in others one task might handle the events from several windows. It's a question of what the problem's concurrency needs are, not what the windowing system forces on you. You wouldn't be forced to declare any tasks, if tasking's not appropriate to the problem. > > 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. There can be an awful lot of different events from a window. I would think you could tell the system what events to report and which to ignore, with a default set that is frequently useful. Then, if you're only interested in the close event from a window, it won't send you anything else. > > 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. This is the approach taken by CLAW. A widget is represented by a tagged type, with primitive operations that are called automatically when certain events occur. There are default versions of these operations. To create a widget with specific behavior, you have to extend the type and override the appropriate operations. This can be useful when you want to have data associated with a widget, as you can define the data as part of the extension, give the widget values when you create it, and check the values in the operations. But when all you want is to define the application's behavior when the user clicks a button, it seems like overkill. Consider a window with lots of buttons, different behavior when each button is clicked, and little or nothing else in the way of user input. This calls for many extensions and many overridings of the appropriate operation. It differs from callbacks in not requiring operations to be registered with the windowing system, but similar in that the windowing system controls your application. > I can't speak for CLAW, and the one shortcoming I see in JEWL is that > you cannot get "focus events". JEWL is deliberately a simple system, and the lack of some features is the price of that simplicity. The concept of the application actively requesting events from the windowing system is one that could be applied to a more complex windowing system. Nothing's perfect, and GtkAda and CLAW represent a lot of good work. JEWL is very good, too, for its application area of providing a simple windowing system for beginners. -- Jeff Carter "My name is Jim, but most people call me ... Jim." Blazing Saddles