Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!twg.com!david From: david@twg.com (David S. Herron) Newsgroups: comp.windows.x Subject: Re: need information about XVT Keywords: XVT x-development Message-ID: <9150@gollum.twg.com> Date: 24 Jun 91 07:06:56 GMT References: <1991Jun18.205101.28425@colorado.edu> <1991Jun19.173316.18566@alphalpha.com> <1991Jun21.183405.26015@colorado.edu> Organization: The Wollongong Group, Palo Alto, CA Lines: 102 In article <1991Jun21.183405.26015@colorado.edu> thompsog@spot.Colorado.EDU (THOMPSON GEOFF) writes: >In article <1991Jun19.173316.18566@alphalpha.com> nazgul@alphalpha.com (Kee Hinckley) writes: >>In article <1991Jun18.205101.28425@colorado.edu> thompsog@spot.Colorado.EDU (THOMPSON GEOFF) writes: >>>by accessing the native window sytem components of XVT objects. Hence, the >>>term "Extensible." In general, the full capabilties of the native window >>>system are available in non-portable ways, including handling all native >>>system events. >>However, manager-type widgets like forms, rowcolums, tables... are not >>accessable, unless quite a bit has changed since I last looked at XVT. >>In my mind this toss out one of the best features of Xt. As I say many many many many times -- a reasonable toolkit for building these sort of applications should provide facilities like the form & rowcolumn & table widgets. The fact that XVT does not is one of its GREAT LACKS. >In general, if you want to do something non-portably in XVT, you should >be able to do most anything the underlying toolkit, window system, and >operating system allow. Yes.. but why should this be non-portable? That is, why should these features be lacking? Regardless my impression is that bypassing XVT to get to the underlying windowing system is exceedingly hard. Maybe not.. For instance the CURL compiler produces UIL, one could edit that and make it use whatever widgets you wanted... In addition to Kee's objections I have some critisms of XVT. Note that I am first & foremost exceedingly uninterested in PC & MacIntosh portability, I use XVT because the people who pay me want that portability. My use for the MacIntosh in my office is target practice with rubber bands ;-). I have worked in Motif for 1.5 years, and also have a half-completed implementation of an XVT-compatible toolkit. In no particular order ... The API is very inconsistent and rather silly in places. For instance there are a couple of XVT objects which keep lines of text. They have an almost useful data structure, the SLIST (Which seems to be "struct SLIST {char *s; long data; struct SLIST *next;}") but which is used for only one of these objects. Another facet is in specifying location/size of a rectangle (for locating an object on the screen). In some instances you specify {x,y,width,height} and in others it is {top,left,bottom,right}. programmer gets involved at too low a level -- There are a couple of aspects to this. For instance, the way you design a window is to drag out some graph paper and measure out x&y coordinates. For instance, the program gets told of some very uninteresting events. Like if the mouse is clicked anywhere with one of my windows an event is generated.. I cannot imagine wanting to be interested in that, unless the window had a "drawing area" in it. Instead I, as a programmer, am only interested in whether a button was pushed, or an item in a listbox was selected, or whatever. There should be a way to tell XVT to not generate those events. the events are backwards from what they should be -- The structure of programs are much like how I understand that Microsoft WINDOWS programs are structured. That is.. each window has a single routine into which ALL the events are funneled. This is every single last one including mouse location reports. (Actually, XVT doesn't report mouse locations unless the mouse is dragging something.. it is WINDOWS which does this). Then events which the application programmer is uninterested in are passed into a standard routine in the toolkit. This is very different from how Xt programmers, like myself, expect programs to be organized. Instead we only get events of interest, and instead of being delivered to one routine which holds the world they are delivered to their own individual routines. A reason this is important has to do with common-courtesy in a multi-tasking system. WINDOWS can get away with throwing away CPU power on notifying application programs of events they aren't going to be interested in because it's a single tasking computer. X, on the other hand, has to not only share the system but also the ethernet cable with other processes. Therefore delivering uninteresting events should be highly frowned upon. it really is the least common denominator -- People have tried to claim otherwise. But they are wrong. You have available a very small set of objects (text entry & display, buttons, listboxes, scrollbars and drawing primitives) and no way to extend these in useful/interesting/object-oriented ways. Weeell, they do have a C++ toolkit/front-end, dunno how useful it is but the blurb didn't sound too promising. Like Kee said above, it does not provide any interesting facilities... David -- <- David Herron, an MMDF & WIN/MHS guy, <- <- <- "MS-DOS? Where we're going we don't need MS-DOS." --Back To The Future