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 13:39:06 PST Message-ID: <3E5549EB.1050907@cogeco.ca> From: "Warren W. Gay VE3WWG" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 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> <3E51A55A.3000101@cogeco.ca> <3E52A1BF.1020809@cogeco.ca> <3E53CCDF.1090509@cogeco.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 20 Feb 2003 16:34:35 -0500 NNTP-Posting-Host: 198.96.47.195 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1045776876 198.96.47.195 (Thu, 20 Feb 2003 16:34:36 EST) NNTP-Posting-Date: Thu, 20 Feb 2003 16:34:36 EST Organization: Bell Sympatico Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!cyclone.bc.net!torn!webster!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail Xref: archiver1.google.com comp.lang.ada:34305 Date: 2003-02-20T16:34:35-05:00 List-Id: Randy Brukardt wrote: > 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. It took a little convincing, but I am sold on this now ;-) >>>>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, Yes, I agree with this. > 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. I tend to put "overhead" in the lowest category as long as the overhead is "reasonable"; at least for projects like a UI. I would personally rate your last two points higher for example, if I were to rate them (all of them goals that I would agree with). > 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. That's what I prefer to see, for sure : long term goals with long term payoffs. >>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. Yes. In fact, more than this.. 8-O I liked your idea of taking what I call the "application context" object and extending it to provide the access to the user data. By doing this, I was able to eliminate a system.address and a ghastly generic procedure to convert address to User_Data_Ptr. The only downside to this, is that the user must continually "convert" the ACTX_Type to a User_Data type, to reference members (the ACTX_Type is a controlled limited type). type User_Data is new ACTX_Type with record Whatever : Boolean; -- User data member(s) end; procedure Callback(ACTX : ACTX_Type'Class; ...) is begin User_Data(ACTX).Whatever := True; ... I suppose if you have many refs to the user data type, you can call a procedure with the type converted as in: Yet_Another_Proc(User_Data(ACTX),...) where procedure Yet_Another_Proc(UD : in out User_Data; ...) is begin UD.Whatever := ...; as either an internal or external procedure. Thanks for the effort of convincing ;-) -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg