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-20 11:39:45 PST Path: archiver1.google.com!news1.google.com!sn-xit-02!sn-xit-04!sn-xit-06!sn-post-02!sn-post-01!supernews.com!corp.supernews.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: [OT] Best way to isolate a GUI? Date: Thu, 20 Feb 2003 13:39:17 -0600 Organization: Posted via Supernews, http://www.supernews.com Message-ID: References: <3E511C15.1040404@acm.org> <3E5121BD.4010200@cogeco.ca> <3E51A55A.3000101@cogeco.ca> <3E52A1BF.1020809@cogeco.ca> <3E53CCDF.1090509@cogeco.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Newsreader: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3719.2500 X-Complaints-To: abuse@supernews.com Xref: archiver1.google.com comp.lang.ada:34295 Date: 2003-02-20T13:39:17-06:00 List-Id: Warren W. Gay VE3WWG wrote in message <3E53CCDF.1090509@cogeco.ca>... >Randy Brukardt wrote: >> In any case, my point is that there are a lot more kinds of events in >> the full-blown GUI than there are in X11 itself. (I should point out >> that its been years since I've had any reason to look at X11, so I'm >> working from old memories of X.) > >I won't disagree with that. In fact, to some degree, I think you've >managed to successfully present the tagged record approach as a good >callback approach for two reasons that I would consider key: > > 1. Reduces one central "definition" of the event to a base type (or set) > 2. Allows easy extendability of the event object as new widgets > are developed. Yes, exactly. These are precisely why we used the tagged approach. >>>But my point has always been in this >>>thread is that there has been no good reason given that event data >>>cannot be provided in a callback parameter as a variant record. >> >> For simple events, I prefer to simply provide the data as parameters to >> the action routine (the event handler that you override in an OOP GUI >> like Claw). And, if the events are sufficiently different, I'll provide >> different routines for them. For example, I certainly see no reason to >> share the handler for a keypress and a mouse click. That usually >> eliminates the need for complex data structures of any sort. > > From a "client perspective", I would agree with this. But with my >library writer's hat on I don't because that means I have to define >different collections of callbacks. Whereas if you define one type >of callback interface, say something like: > > procedure Callback(W : Widget_Type; Event : Event_Type'Class; User_Data_Ref : ...); > >then you can centralize code to call a callback list, add to and delete >from the callback list. All widgets can then be built to use the same >resources. Remember the ease of writing is WAY down on the list of good things for Ada, and we certainly followed this approach with Claw. Our goals for the interface were (not necessarily in this order): -- Avoid unnecessary overhead in the implementation of the interface; -- Insure that the interface prevents common errors, preferably at compile-time; -- Make the interface easy to use for the client. Our effort in writing the interface was never an issue. Of course, we expect many people to use it, and thus the effort spent in meeting the goals will pay off over time. >Ok. You have sold me on tagged types for the event info. However, I >still some application for variants within those tagged types ;-) Like Marin, I'll never say "never use" something, because that's silly. If a variant makes sense in a particular extension, by all means use it. But the base item should be a tagged root type of some sort, not a massive variant. I think we finally agree. Randy.