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