zee@fwi.uva.nl (Daniel M. van der Zee (I89)) (06/17/91)
About two weeks ago i posted a message about x-developing the same app for mac, x & ms windows. I got a lot of replies suggesting i should take a look at XVT. The only thing i know about XVT so far is that it is a collection of header files and libraries that create a layer between the operating system of various GUIs and my program. What i fear is that to use XVT i have to learn to program yet another operating system from the ground up. (I well remember the horror of trying to understand the first three issues of Inside Macintosh). I would like to have some more info about XVT before actually looking at it myself. If you have some time left and you've used XVT yourself i would appreciate some answers to the questions below (for most questions a simple Yes or No will do): 1 Is XVT just a collection of "low-level" functions that translate the params to the OS its running on? 2 Does XVT contain a large class library for speeding up application development? (if so how does it compare to MacApp) Is it good? (does XVT speed up application development for applications that will have to run on one platform only?) 3 Does XVT cover more than the parts all GUIs have in common or does it try to add good things from one GUI to the other? 4. Has printing be implemented? How hard is printing (compared to mac) 5. Has a text-edit object been implemented? Can it handle multiple fonts in one object? What is the limit to the number of chars in such an object? Are there any other limitations? 6. Are resource definition files translated to all GUIs? 7. What are the strengths of XVT? 8. Is there something you cannot do with XVT? 9. What compilers does XVT work with? (Please excuse my english and ignore my spelling errors) Thank you very much, Daniel van der Zee Student Computer Science University Of Amsterdam The Netherlands e-mail: zee@fwi.uva.nl
thompsog@spot.Colorado.EDU (THOMPSON GEOFF) (06/19/91)
> If you have some time left and you've used XVT yourself i would appreciate > some answers to the questions below Before answering your questions here's a brief introduction: XVT, the Extensible Virtual Toolkit, provides a single application interface to multiple window system platforms. These include the Macintosh, Microsoft Windows on DOS, Presentation Manager on OS/2, X/Motif (on Sun 680x0, Sun SPARC, Interactive 386/ix, SCO XENIX, IBM RISC 6000, VAX DECstation, HP9000, VAX VMS), X/OPENLOOK (to be shipped later this year), AND character terminals on DOS and UNIX. XVT gives you the potential to have a single body of source code which is portable across all of the supported platforms. XVT provides windows, menus, dialog boxes, buttons, list boxes, graphics, and keyboard and mouse input (plus much more). All of these capabilities are implemented on all platforms, (except graphics is obviously limited on the character based systems). XVT is NOT the least common set of window features across all platforms. It is a set of abstractions to window system programming which are implemented on each platform. In the cases where XVT can not meet all the needs of a program on a particular platform, XVT enables the programmer to extend the application's capabilities 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. Now for your questions: > 1 Is XVT just a collection of "low-level" functions that translate the params > to the OS its running on? XVT is a layer between the application and the native window system. The window system is usually a layer on top of the OS. (In the case of the Mac, there is not clear distinction between OS and window system.) XVT is best thought of as a set of window system abstractions (windows, events, drawing functions) which are used in programming applications with a GUI. On some platforms an abstraction has a direct correspondence to the native window system, so an XVT function translates very simply to a native window system function; however on other platforms, the same abtraction may not exist, so XVT implements it in its layer. > 2 Does XVT contain a large class library for speeding up application > development? (if so how does it compare to MacApp) > Is it good? (does XVT speed up application development for applications > that will have to run on one platform only?) XVT does not use a class library concept, although on some platforms there is a direct correpsondence between XVT abstractions and classes in the native window system. However, the abstractions are well chosen, and XVT does indeed speed up development on each platform, as compared to developing in the native window system or toolkit. For example, I prototype applications on a Mac which ulitimately are meant to run on a Sun sparc station using the Motif toolkit on X. I know very little about Mac OS or window system internals, yet I have created several Mac applications quickly. > 3 Does XVT cover more than the parts all GUIs have in common or does it try > to add good things from one GUI to the other? XVT is much more than a collection of least common features, it has added several well chosen features. > 4. Has printing be implemented? > How hard is printing (compared to mac) XVT does include printing in its abstractions. An application simply opens a print window, draws into it using the same code for drawing into a screen window, and closes the print window. (There are some details about starting and ending a page which are not part of screen drawing that must be handled.) But in general, you draw to the printer the way you draw to a window. This is a great bonus for XVT on X, since there is no printing functionality in X lib or any of the Intrisnics based toolkits. > 5. Has a text-edit object been implemented? Yes. > Can it handle multiple fonts in one object? No, but this may change soon. Check with XVT for details on this in the next release (Release 3). > What is the limit to the number of chars in such an object? Implementation dependent. I'm not sure but the limit is probably the number of characters that can be addresses with an unsigned short. > Are there any other limitations? That depends on your needs. In general, the XVT text edit object is a very flexible "editor in a rectangle" which features such as: insert or manipulate text from the application; enable/disable user editing; control whether text is wrapped or not; include borders or not; limit number of characters per paragraph or whole object (useful for forms entry); enable/disable cut, copy, and paste; enable/diasable scrolling; and all attributes can be changed dynamically. > 6. Are resource definition files translated to all GUIs? Yes, currently this is done through a text file which describes the XVT resources and is compiled into the native resource description. Later this year a graphical resource editor for doing this will be released. > 7. What are the strengths of XVT? By far, the greatest strength is portability of programs across multiple window system platforms. The second greatest strength is the capability of developing GUI programs quicky for each of the supported platforms. > 8. Is there something you cannot do with XVT? Some things aren't easy, but the entire capabilities of the native window system and native OS are always available if they are needed. > 9. What compilers does XVT work with? XVT supports most of the major compilers for each platform XVT runs on. Hope this helps. I'm sure you could have many more questions. To get a thorough technical description contact XVT Software Inc. 1800 30th Street Box 17665 Boulder, CO 80308 (303) 443-4223 FAX (303) 443-0969 As a favor, if you do contact them, please let them know you heard from me. Thanks, Geoff Thompson independent software consultant
nazgul@alphalpha.com (Kee Hinckley) (06/20/91)
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. -- Alfalfa Software, Inc. | Poste: The EMail for Unix nazgul@alfalfa.com | Send Anything... Anywhere 617/646-7703 (voice/fax) | info@alfalfa.com I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
bill@polygen.uucp (Bill Poitras) (06/21/91)
In article <1991Jun17.130007.16913@fwi.uva.nl> zee@fwi.uva.nl (Daniel M. van der Zee (I89)) writes: >(for most questions a simple Yes or No will do): > >1 Is XVT just a collection of "low-level" functions that translate the params > to the OS its running on? No. Although XVT doesn't contain almost a one to one tranlation, there are a bunch of stuff that is not low-level. > >2 Does XVT contain a large class library for speeding up application > development? (if so how does it compare to MacApp) What do mean? A C++ class library (to which the answer is yes) or something else. Please let me know, for I have never used MacApp. > Is it good? (does XVT speed up application development for applications > that will have to run on one platform only?) > >3 Does XVT cover more than the parts all GUIs have in common or does it try > to add good things from one GUI to the other? The latter. Some of the things it adds: child windows and text edit object for the mac, a standard way to print for Motif (done ala windows) and a simple font mapper much like windows. > >4. Has printing be implemented? Yes. > How hard is printing (compared to mac) Probably a little easier. It still uses the idea of "banding", but if you write your applications so all your drawing is in one procedure, you can print very much like you draw to the screen. > >5. Has a text-edit object been implemented? Yes, on all platforms. > Can it handle multiple fonts in one object? No. > What is the limit to the number of chars in such an object? Don't remember. > Are there any other limitations? Don't remember. > >6. Are resource definition files translated to all GUIs? Yes, both to and from. e.g. you can create a dialog in the Windows Dialog editor and convert it to CURL (XVT's resource language) which then can be converted into UIL or Mac resource. > >7. What are the strengths of XVT? - Portable resources - Royalty free C callable libraries - High level functions on all platforms (Printing, clipboard handling) - Ability to call native windows system - Supports Windows 3.0 Mac OS/2 Motif (on many platforms) Open Look (in Beta) Character based window system (many platforms) > >8. Is there something you cannot do with XVT? Yes - Portable bitmap creation - Major functionality that doesn't exist on all platforms (DDE, QuickDraw...) > >9. What compilers does XVT work with? Windows - BC, MSC 5.1+, Zortech C Mac - Lightspeed C, and one other Motif - Whatever platform uses (ANSI compilers) Any specific questions, let me know (anyone) +-----------------+---------------------------+-----------------------------+ | Bill Poitras | Polygen Corporation | {princeton bu}!polygen!bill | | (bill) | Waltham, MA USA | - This space for rent - | | | FAX (617)890-8694 | bill@polygen.com | +-----------------+---------------------------+-----------------------------+
thompsog@spot.Colorado.EDU (THOMPSON GEOFF) (06/22/91)
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. >-- >Alfalfa Software, Inc. | Poste: The EMail for Unix >nazgul@alfalfa.com | Send Anything... Anywhere >617/646-7703 (voice/fax) | info@alfalfa.com > >I'm not sure which upsets me more: that people are so unwilling to accept >responsibility for their own actions, or that they are so eager to regulate >everyone else's. 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. You make a good point however. In fact, I will be presenting a talk at the upcoming XVT Conference this August which will include the topic of "How to add an arbitrary motif widget to an XVT window." 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. Geoff Thompson independent software consultant
david@twg.com (David S. Herron) (06/24/91)
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, <david@twg.com> <- <- <- "MS-DOS? Where we're going we don't need MS-DOS." --Back To The Future
david@twg.com (David S. Herron) (06/24/91)
Oh yea.. forgot to say some good things about XVT while I got caught up in the fervor of denigrating it. It really does seem to be faster to code in than Motif. Or perhaps it's just my relative level of experience when I started with XVT than with Motif. After all, when I started with Motif last year I had never written any interactive program (on a graphical interface or not) before. But when I started with XVT last december I had written 30,000+ lines of Motif. Another person in my group started working in XVT recently. Previously he'd been working on device drivers and performance improvements, etc. I don't think he'd done any GUI work. He didn't seem to have much trouble picking it up and even came up with a useful technique for structuring XVT programs so that main_event() is less cluttered. So it's easier to learn, but much less powerful than Motif. Oh yeah.. it is possible to write a geometry manager module for XVT programs. I recently had to do that. Started with the description of the box "widget" in the Interviews library and implemented that. It took 4-5 days but isn't finished either since the programming interface to the module isn't very nice (right now) and neither does it do all the Right Things. -- <- David Herron, an MMDF & WIN/MHS guy, <david@twg.com> <- <- <- "MS-DOS? Where we're going we don't need MS-DOS." --Back To The Future
marbru@auto-trol.com (Martin Brunecky) (06/25/91)
n article <9152@gollum.twg.com> david@twg.com (David S. Herron) writes: >Oh yea.. forgot to say some good things about XVT while I >got caught up in the fervor of denigrating it. > >It really does seem to be faster to code in than Motif. Or >perhaps it's just my relative level of experience when I started >with XVT than with Motif. After all, when I started with Motif >last year I had never written any interactive program (on a >graphical interface or not) before. But when I started with >XVT last december I had written 30,000+ lines of Motif. > The common mistake people do with Xt based toolkits (including Motif), is that the *CODE*. Coding may be appropriate as a part of the Xt learning process, so most books you can get on the subject DO coding. Coding is necessary evil to add dynamics and do a fwe special things. However, with Xt based toolkits you should NOT code the UI, only the application. The UI LAYOUT(s) should be DEFINED, either using Wcl or (Gor forbid-) UIL, never CODED. Of course, if you have the bucks, then using some of the UI layout design tools is handy - again, you do not CODE the interface, you define it. Our experience shows that avoiding CODING during the learning process is also very beneficial: The "treinee" concentrates his attention onto manipulating widgets through resources, and learning the palette of the available widgets. Rather than starting with XtMakeGeometryRequest call which (for whatever reason) some novices find so tempting. Which takes me to my question. Does XVT include some kind of UI defintion format, that allows to DEFINE the user interface without CODING ? -- =*= Opinions presented here are solely of my own and not those of Auto-trol =*= Martin Brunecky marbru%auto-trol@sunpeaks.central.sun.com (303) 252-2499 (better avoid: marbru@auto-trol.COM ) Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404
nazgul@alphalpha.com (Kee Hinckley) (06/25/91)
In article <1991Jun21.183405.26015@colorado.edu> thompsog@spot.Colorado.EDU (THOMPSON GEOFF) writes: >operating system allow. You make a good point however. In fact, I will >be presenting a talk at the upcoming XVT Conference this August which XVT Conference? When, where? >will include the topic of "How to add an arbitrary motif widget to an >XVT window." 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. 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. -- Alfalfa Software, Inc. | Poste: The EMail for Unix nazgul@alfalfa.com | Send Anything... Anywhere 617/646-7703 (voice/fax) | info@alfalfa.com I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
imp@solbourne.com (Warner Losh) (06/27/91)
In article <1991Jun24.195803.10980@alphalpha.com> nazgul@alphalpha.com (Kee Hinckley) writes: >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. While it is true that you can't mix OI and Xt, you do have the same functionality. Since OI version 1.1 (released about a year ago) any object can have a layout method assocaited with it (which is slightly different than the Xt approach where you have to derive your widget from a manager superclass). This layout method tells the object how to layout its children. Isn't that basically the same thing as the manager widget? You work in row,column positions rather than x,y coordinates. The row and column positions are independent of the sizes of the objects. For example, if you wanted to put a glyph inside of a box and have some text centered under it, you could do it in the following 47 lines of code (including comments): #include <OI/oi.H> #include <sysent.h> int main (int argc, char **argv) { OI_connection *conp; OI_box *boxp; OI_glyph *glyphp; OI_static_text *textp; // // Initialize OI. // if ((conp = OI_init (&argc, argv, "Hello", "Hello World")) == NULL){ fprintf (stderr, "Can't connect to X server\n"); exit (1); } // // Create a box to put some stuff in. Set the layout method. // boxp = oi_create_box ("container", 1, 1); boxp->set_layout (OI_layout_row); // // Create the glyph to put in the box. Put it in row 1. // glyphp = oi_create_glyph ("glyph", "/usr/include/X11/bitmaps/xlogo32"); glyphp->set_gravity (OI_grav_center); glyphp->layout_associated_object (boxp, 0, 1, OI_ACTIVE); // // Create the text to put in the box. Put it in row 2. // textp = oi_create_static_text ("text", "Hello World"); textp->set_gravity (OI_grav_center); textp->layout_associated_object (boxp, 0, 2, OI_ACTIVE); // // Put the box on the screen and start the interaction. // boxp->set_associated_object (boxp->root(), OI_DEF_LOC, OI_DEF_LOC, OI_ACTIVE); OI_begin_interaction(); OI_fini(); return 0; } As you can see, I didn't need to know the size of anything to get stuff to layout correctly. The user can change the size of either the glyph or the static text through the use of resources (by changing the icon image, or the contents of the text string). The program will still center these two objects in a box. Warner -- Warner Losh imp@Solbourne.COM But it was our hill. And they were our beans.
david@twg.com (David S. Herron) (06/27/91)
[followups redirected to comp.windows.misc since this isn't talking about X any longer.. kinda] In article <1991Jun24.171429.13200@auto-trol.com> marbru@auto-trol.com (Martin Brunecky) writes: > The common mistake people do with Xt based toolkits (including Motif), > is that the *CODE*. > Coding may be appropriate as a part of the Xt learning process, so most > books you can get on the subject DO coding. Coding is necessary evil > to add dynamics and do a fwe special things. Ok.. I can see that now. But a year ago when I didn't have the foggiest idea how to do Motif & all I had was the OSF Programmers Guide ... > However, with Xt based toolkits you should NOT code the UI, only the > application. The UI LAYOUT(s) should be DEFINED, either using Wcl or > (Gor forbid-) UIL, never CODED. Of course, if you have the bucks, > then using some of the UI layout design tools is handy - again, you > do not CODE the interface, you define it. > > Our experience shows that avoiding CODING during the learning process > is also very beneficial: The "treinee" concentrates his attention onto > manipulating widgets through resources, and learning the palette of > the available widgets. Rather than starting with XtMakeGeometryRequest > call which (for whatever reason) some novices find so tempting. > >Which takes me to my question. Does XVT include some kind of UI defintion >format, that allows to DEFINE the user interface without CODING ? Yes.. at least for the dialog's and menu structure. The menu structure you define as MENU <tag> <label> ITEM <tag> <label> <options> ... SEPARATOR <tag> is a number which is used internally to figure out which menu entry was selected. They have a macro to help construct this number ... MAKE_MENU_TAG(menu, item) <label> is the string <options> are optional, and can be "disabled", "checkable" or "checked". Cascaded menus are not supported. The <tag> definition is normally put in a #include file which is included by both the URL file & .c files. Then dialogs are declared like so: DIALOG <id> <rect> [ <title> [ <type> ]] <object> <id> <rect> <information> <id> is a number used to refer to either the dialog or the object. There is one "number space" for dialogs, and for each dialog there is a separate "number space" for those objects. When creating a dialog you refer to the number. When within the call-scope of the callback routine for a dialog you refer to objects in the dialog by their <id>. <rect> is (x, y, width, height) specification of where the dialog is on the screen, or the object is within the dialog's window. <title> is what to put in the title bar. <type> is either MODAL or MODELESS, but seems to be ignored because when one calls new_dialog() the same value is repeated. The difference is that MODAL dialog's do not return from new_dialog() until the dialog is closed. <object> is BUTTON, CHECKBOX, RADIOBUTTON, EDIT (one-line only), TEXT (e.g. an XmLabel), LISTBOX, SCROLLBAR or ICON (picture button). There are two kinds of windows.. I call them dialog-window's and window-window's. Building a dialog-window is as above. They do not carry menu bar's and do not generate events into the main_event() routine. Therefore one cannot control the look of a dialog-window programmatically & they must be defined statically at compile time (!). window-window's have a menu bar, generate events into main_event() and so forth. Their contents can be constructed at runtime but can only be chosen from a small set of the <object>'s listed above. Also operating upon the objects is different depending on whether it is in a dialog-window or a window-window. For instance to set the label on a button (or text) object, one calls set_item_text() if it is in a dialog-window, but set_title() if it is in a window-window. But the documentation for set_title() reads as if it sets the string in the title-bar because it says it acts on a WINDOW pointer. window-window's generate size events (E_SIZE) and my geometry manager module for XVT is triggered by that event. Have fun, gotta run! David -- <- David Herron, an MMDF & WIN/MHS guy, <david@twg.com> <- <- <- "MS-DOS? Where we're going we don't need MS-DOS." --Back To The Future
nazgul@alphalpha.com (Kee Hinckley) (06/27/91)
In article <1991Jun26.204244.29527@solbourne.com> imp@solbourne.com (Warner Losh) writes: >In article <1991Jun24.195803.10980@alphalpha.com> nazgul@alphalpha.com (Kee Hinckley) writes: >>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. > >While it is true that you can't mix OI and Xt, you do have the same >functionality. Since OI version 1.1 (released about a year ago) any True I'm sure. But OI isn't a virtual toolkit. It's a toolkit that supports two style guides. XVT is a virtual toolkit in the sense that it is layered on top of other toolkits. -- Alfalfa Software, Inc. | Poste: The EMail for Unix nazgul@alfalfa.com | Send Anything... Anywhere 617/646-7703 (voice/fax) | info@alfalfa.com I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
bill@polygen.uucp (Bill Poitras) (06/28/91)
In article <1991Jun24.171429.13200@auto-trol.com> marbru@auto-trol.com (Martin Brunecky) writes: >Which takes me to my question. Does XVT include some kind of UI defintion >format, that allows to DEFINE the user interface without CODING ? XVT does have a resource file format similar to Window RC files. But that only is for defining dialogs, menus, and a few others. Since XVT doesn't support containers (Form widgets for examples) you can't code the GUI in the resource files. However, they have a GUI layout tool in beta which will write resource files and maybe skeleton code for the application user interface, but I don't remember. +-----------------+---------------------------+-----------------------------+ | Bill Poitras | Polygen Corporation | {princeton bu}!polygen!bill | | (bill) | Waltham, MA USA | - This space for rent - | | | FAX (617)890-8694 | bill@polygen.com | +-----------------+---------------------------+-----------------------------+