thompsog@spot.Colorado.EDU (THOMPSON GEOFF) (06/26/91)
In several previous articles: ... (Geoff Thompson) writes: >>With regards to XVT ... >>It is my belief that any widget should be accessible, >>but the real question I need to explore is, just how hard will this >>be. Now I'm not sure how much this would go to satisfy your point, but >>I do intend to answer the general question of creating a widget, putting >>it in an XVT window, and handling its related callbacks. I won't know the >>results for a while, since I wont be doing that work until next month. and (Kee Hinckley) write: >My problem with XVT in this respect (I have other problems in other >respects :-) is not adding arbitrary widget children - but adding >widget parents. XVT, like the PC toolkits it started on, has no >concept of geometry management. Everything is based on an X/Y >coordinate system (many IDTs also have this flaw). One of the >great thing about Motif (and most other Xt-based toolkits) is that >I can specify a very complex interface without ever once caring about >the size of fonts or other objects. Everything can be layed out >in a relative manner. If the user changes the font (or language!) >it doesn't matter - it just works. However I am not aware of any >virtual toolkits which allow you to take one of those manager widgets >(Table comes to mind) and put their "virtual" widgets inside of it. With your clarification I now understand your original point. You are correct, XVT does not have the concept of geometry management. As you state, this is reflective of the of the 2 platforms XVT was originally built for (Mac and MS Windows). It is also reflective of the original goals of XVT, to provide a "thin" layer between application and window system. Geometry management simply conflicts with that goal. If geometry management is an important characteristic of the way an application is to be programmed, then XVT is probably not an appropriate tool. Geoff Thompson independent software consultant