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-19 10:32:23 PST Message-ID: <3E53CCDF.1090509@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> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 19 Feb 2003 13:28:47 -0500 NNTP-Posting-Host: 198.96.47.195 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1045679330 198.96.47.195 (Wed, 19 Feb 2003 13:28:50 EST) NNTP-Posting-Date: Wed, 19 Feb 2003 13:28:50 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:34230 Date: 2003-02-19T13:28:47-05:00 List-Id: Randy Brukardt wrote: > Warren W. Gay VE3WWG wrote in message <3E52A1BF.1020809@cogeco.ca>... >>Randy Brukardt wrote: >>>That's usually not practical. The notification >>>data includes various data types specific to each of the types of >>>controls. >> >>OK, I can see that you might have some package interdependency >>issues, depending on the data _types_ being used. I do believe >>however, that careful planning can avoid these problems. > > Not practical, unless you plan to eliminate most type checking (that is, > most of the advantages of Ada). I disagree. You can combine a base class (tagged record) with variant records. This gives you the best of both worlds. >>>If we had to put all of that in the spec. of the Claw root >>>package, we'd more than double its size (and its already 5000 lines). >> >>So? What problem? Longer compile times? Is that what we're worried >>about? It may be a consideration, but not necessarily a >>deciding factor. > > Readability, of course. And excess coupling. (It's the coupling that > causes other things to be dragged in). > >>>If we had used a variant solution, there >>>would be no possibility of that, as every possible control would have to >>>be reflected in that variant. >> >>This is patently false. >> >>I don't believe that just because a variant record is used that this >>eliminates the possibility of a cleanup. The reason is this: you only >>carry _EVENT_ data in this variant record -- not widget internal data. >>This event data can be used to communicate with many widget callbacks. >> >>Perhaps you misunderstand what I am suggesting here -- I am not >>suggesting widgets in a variant record. Oh, no! Only _event_ data. > > I'm only talking about "event" data. Let's look at some of the > notification event data. > > For a tree view control, the standard notification includes the > following components: > Old_Item_Handle, New_Item_Handle, Old_Item_State, New_Item_State, > Old_Item_DWord, > New_Item_DWord, Action, and Point. > The notification gets sent when the selection changes, when an item is > expanded (or contracted), when an item is deleted, when an item is > dragged, and more. > > In order to make this into a possible variant, we'd have to pull all of > the handle and state declarations into the root Claw package. OK, but why not use a tagged "base type" for the event data. Then for callbacks that need "extended event data", you can test and convert the type to the type it really is. But, within the tagged type, you can still make use of variant records for those events that vary according to purpose/event. The variants can exist at both the base level and at the "extended level". I still do not see anything here that precludes the use of variant records. ... >>>Since we used a tagged type, we don't have >>>to drag in Tree Views unless the user actually withs Claw.Tree_View. >>>(That was happening for another reason, and the internal restructuring >>>eliminated that.) That cut the average size of Claw programs by 500K. >> >>Look at the way XEvents is defined. It does not define a member for each >>widget. It defines a view for each _event_ type. The members correspond to >>needs of the _event_ _communication_. Nothing you have said has invalidated >>this approach. > > I think you have a completely different idea of what an event is than I > do. You're thinking at the level of X11, which is a low-level graphics > environment. It has very simple events like "mouse moved" and "key > pressed". This is true of course. I grabbed the MOTIF book off of the shelf this morning (before breakfast even ;-) and reviewed the callbacks that it and the Xt (intrinsics) define in the callback interface. It is true that they use a different "model" interface: they provide two XtPointer values in addition to the widget. The callback code then is expected to cast this pointer to the correct structure type, which, IMHO is ghastly. So you do have a point -- I'll concede at this level. :( However, I still think that a combination of a base tagged type with the use of variant records would provide the best of all solutions for the callback interface. I guess your point is probably why use variant records at all, when tagged records will do? I need to think about that more, but the one objection I have is that it is easier to case on the record's discriminant then to do "if event in Some_Widget'Class then" tests in code that needs to perform those tests. > While those are clearly events, there are also events specific to a > particular control (or widget, if you prefer), like "Button pressed". > And most importantly for this discussion, there are events that are > meaningful for many controls, like "item selected". The data that gets > sent with a "item selected" event is specific to the control that sent > it, but the event is common to all controls. Agreed. Which I suppose is why you like the tagged record approach. I am not entirely disagreeing at this point, but I still seem room for variant record "participation" ;-) Certainly as you've pointed out, the tagged record approach allows you to bury its specifics in other package specs. I have to admit that I like that. >>>But that's a pretty limited GUI (and calling X11 a GUI is a stretch). >> >>Um, MOTIF, which is used UNIX-wide, is entirely built upon X11. >>Not to mention that Gtk also builds upon X11 in the environments >>that require it. The X intrinsics build upon X11 to provide the >>widget foundation and callbacks, that other widget sets in X use >>(like MOTIF/LessTif). All of these layers use callbacks and >>event data. If this aint a serious GUI, then tell me why >>the LessTif team has taken several years to duplicate MOTIF 2? ;-) >>It is, and continues to be. > > > MOTIF is a GUI. X11 is not; it's more of a toolkit for building GUIs. > Windows is built on top of GDI, but I don't think anyone would call GDI > a GUI. Well, OK. But we're splitting straws here I think -- X11 is graphical, it is an interface, and it is used by a user (hence GUI). There are some (albiet limited) applications that only make use of the X11 library. But I'll concede the point, if it helps. > 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. >>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. > > Randy. 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. Ok. You have sold me on tagged types for the event info. However, I still some application for variants within those tagged types ;-) -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg