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 15:19:26 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!sn-xit-03!sn-xit-06!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: Tue, 18 Feb 2003 17:20:55 -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> 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:34214 Date: 2003-02-18T17:20:55-06:00 List-Id: Warren W. Gay VE3WWG wrote in message <3E52A1BF.1020809@cogeco.ca>... >Randy Brukardt wrote: >> 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? Keep reading... >> 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). >> 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. (States are usually private types in Claw along with a set of constants and operations -- no direct bit operations). That would be a lot of excess coupling. Moreover, we'd need to do that for every type of control that has its own distinct state; there are around ten of them currently. We'd also have to expose (unsafely) much more of the low level guts of Claw. For instance, we use the 'user-defined dword' to hold an access to the Ada version of the item. In our interface, we simply declare this to be: Old_Item : Claw.Tree_View.Any_Item_Access_Type; But, if we moved that to the root Claw as you suggest, we wouldn't be able to use the access type (not without moving the bulk of the Tree_View package into the root Claw -- surely you can't be suggesting that!). So, we'd have to open this up to some sort of user conversions, both more error-prone and more likely to be abused. Of course lumping all of that into the Claw root package makes all of those things harder to find, as it is no longer declared with its related code. Root packages should be as small as possible, not full of unrelated garbage. Anyway, my position is very simple: minimizing coupling is good. And having to put stuff in a variant in a root package that doesn't logically belong there is unnecessary (bad coupling). >> 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". 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. >> 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. 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.) >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.