Xref: utzoo comp.windows.x:38025 comp.windows.misc:2161
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,comp.windows.misc
Subject: Re: need information about XVT
Keywords: XVT x-development
Message-ID: <9186@gollum.twg.com>
Date: 27 Jun 91 02:29:23 GMT
References: <9150@gollum.twg.com> <9152@gollum.twg.com> <1991Jun24.171429.13200@auto-trol.com>
Followup-To: comp.windows.misc
Organization: The Wollongong Group, Palo Alto, CA
Lines: 98

[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