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-18 13:13:46 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!skynet.be!skynet.be!freenix!deine.net!feed.cgocable.net!read2.cgocable.net.POSTED!53ab2750!not-for-mail Message-ID: <3E52A1BF.1020809@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> <3E51A55A.3000101@cogeco.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 18 Feb 2003 16:12:31 -0500 NNTP-Posting-Host: 24.150.168.167 X-Complaints-To: abuse@cogeco.ca X-Trace: read2.cgocable.net 1045602777 24.150.168.167 (Tue, 18 Feb 2003 16:12:57 EST) NNTP-Posting-Date: Tue, 18 Feb 2003 16:12:57 EST Organization: Cogeco Cable Xref: archiver1.google.com comp.lang.ada:34213 Date: 2003-02-18T16:12:31-05:00 List-Id: Randy Brukardt wrote: > Warren W. Gay VE3WWG wrote in message <3E51A55A.3000101@cogeco.ca>... >>Randy Brukardt wrote: >>>Warren W. Gay VE3WWG wrote in message <3E5121BD.4010200@cogeco.ca>... >>>>For input and output callback arguments, I use a discriminated record, >>>>which then allows Ada95 checks on record members according to the event >>>>type (ie. the record variation). This is something I wish GtkAda would >>>>use. >>>That doesn't work well if you have callbacks which are evolving (as > most real-world GUIs are). Adding a new variant to a record can break >>>existing code (think aggregates, think name conflicts), and will require >>>recompiling everything in sight. >> >>I don't find this a particularly good argument. I want the code to break >>if I change the callback requirements, even if just for one event. >>Any structure changes are all localized to the variant >>record, so it is very easy to locate conflicts (or simply let the compiler >>do it for you). Of course not all variant record violations can be >>detected at runtime (some can however). >> >>As far as "recompiling everything in sight", I feel this is not a good >>reason to avoid it. If a recompile is necessary (which GNAT _can_ determine), >>then let it compile away. This is an automatic process. >> >>Reluctance to recompile suggests that your goals are not in sync >>with the end user's-- ;-) > > Most end users that I'm familar with don't want to have to rewrite all > of their programs because we've provided an updated version of the > interface with a few new features. New features should not be radically changing callbacks in the first place. Some changes can be made forward compatible, and others might just make more event data available. No problem. > That requires the interface to change > as little as possible. Even adding a parameter can cause problems with > extensions of a type. Adding visible components (which breaks all > aggregates) is simply not acceptable. I would think the assigning of aggregates to a callback should be rather rare, since it is the library producing the callback and the variant record. The callback code is merely "using" the variant record -- not creating it. >>The end goal, IMHO, is to produce a library that provides the best interface >>to the user; not to be convenient to the library developer ;-) > > There is nothing "convenient to the library developer" about either of > these "solutions". The best solution is to not have the problem in the > first place. Thus, we use dedicated action routines (callbacks) whenever > possible. All I am saying is that the callback "event data" can be provided by a variant record, that is customized to the event. This is what the X11 library does (union), and the model works well. > The only place that we use any sort of variable data is in the > lower-level Notification interface, and that's because Microsoft gives > us no choice. Well, this may in fact be part of the reason you made your choice. Interfacing to Microsoft.. say no more ;-) > Note that the notification interface in Windows is defined as a set of > overlayed records, using which ever one is appropriate for the current > message. There is no "variant" and certainly no discriminant. And each > new thing Microsoft adds creates a bunch more of these. And yes, that is the way _Microsoft_ did it. I am just suggesting that in Ada based "systems", it need not be that way. The fact that Microsoft does it one way, in C terms, does not influence what is good and proper in an Ada environment. It only determines the beast you must interface with. > The big problem with the variant interface is that everything has to be > defined in one place. Why is that a problem? XEvent does this too. So? > 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. > 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. > We recently completed a project eliminating as much unused stuff from > user programs as possible. And that is fine and good. Hopefully all library writers do that. > 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. > 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. >>The X11 software (a real world GUI, BTW) uses a finite number of members >>in the XEvent union (albiet in C, and certainly inferior to any Ada95 >>variant record). This model has been well proven and works well. The >>bonus is, that if you insist on a very general structure, this too can >>be accomodated in a variant record with a system.address or some such >>kludge. But at least that kludge is optional, and perhaps temporary as >>your GUI evolves to perfection. > > If you're mapping an existing union, you're way ahead of the game. I'm not mapping an existing union. It is in the discussion as point of reference. > 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. > Windows doesn't work this way, and I doubt that many of the higher level > GUIs built on top of X11 do, either. > > Randy. Windows may be the mess that it is for several reasons. If you have to adapt to it fine. All I have been saying all along though, is that it _need_ _not_ be that way in a new Ada based GUI library. You have practical reasons for the choices you have made, and I'll accept that. 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. You brought some interesting points to the discussion, but none that would convince me that variant records are unsuitable for the job. The only point that came close IMHO was the possible overhead factor. That was a good point, but in my mind, probably not enough reason to avoid it. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg