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 19:39:25 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!c03.atl99!news.webusenet.com!feed.cgocable.net!read1.cgocable.net.POSTED!53ab2750!not-for-mail Message-ID: <3E51AADC.6060702@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> <3E518EA0.1080702@acm.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 17 Feb 2003 22:39:08 -0500 NNTP-Posting-Host: 24.150.168.167 X-Complaints-To: abuse@cogeco.ca X-Trace: read1.cgocable.net 1045539810 24.150.168.167 (Mon, 17 Feb 2003 22:43:30 EST) NNTP-Posting-Date: Mon, 17 Feb 2003 22:43:30 EST Organization: Cogeco Cable Xref: archiver1.google.com comp.lang.ada:34186 Date: 2003-02-17T22:39:08-05:00 List-Id: Jeffrey Carter wrote: > 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. I see two problems developing with this: 1. deciding how to segregate the work between which widgets and tasks (ie. the infrastructure becomes more complicated because you now must decide which windows get their own tasks and which ones don't). 2. Each queue must contain a big case statement for all of the widget cases it must separate the code out for. The callback approach only has to call all registered callbacks for _that_ widget, on its callback list. The callback is already specific to the widget, so no big case statement is required. This queue also suffers from the problem that you would need to code this ahead of time (you must plan a when clause for a particular widget in a queue's event processing section). This makes it more difficult to handle dynamically created widgets (like popups), because you would then have to plan for it in the code. Whereas the callback is already there for any created widget. Since GUIs often have widgets created and destroyed on the fly (like a message box), I can't see this being very practical. The fact that I don't see any GUI framework structured this way yet, suggests to me that there are reasons why this is not practical. However, this is not to say that nobody should try it ;-) >> 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 is easier to call a callback list than to mainain a list of what events to pay attention to or not, IMHO. It is certainly conceptually cleaner. >> 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. Definitely a useful application of tagged records. >> 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. I was not being "critical" of JEWL, but merely pointing out that it does have "limitations". This was one I noticed right away when looking to see if I could make use of it. Certainly for its intended use in teaching, it does a wonderful job with its simple interface. > 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. I don't think anyone was trashing these efforts. It is good to discuss the strengths and weaknesses of the various tools from time to time. Even mine ;-) As software engineers, I think we can handle some constructive remarks from time to time. 8-O -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg