# 
# Copyright (C) 1994, Enterprise Integration Technologies Corp. and Niels Mayer.
# WINTERP 1.15-1.99, Copyright (c) 1993, Niels P. Mayer.
# WINTERP 1.0-1.14, Copyright (c) 1989-1992 Hewlett-Packard Co. and Niels Mayer.
# 
# Permission to use, copy, modify, distribute, and sell this software and its
# documentation for any purpose is hereby granted without fee, provided that
# the above copyright notice appear in all copies and that both that
# copyright notice and this permission notice appear in supporting
# documentation, and that the name of Enterprise Integration Technologies,
# Hewlett-Packard Company, or Niels Mayer not be used in advertising or
# publicity pertaining to distribution of the software without specific,
# written prior permission. Enterprise Integration Technologies, Hewlett-Packard
# Company, and Niels Mayer makes no representations about the suitability of
# this software for any purpose.  It is provided "as is" without express or
# implied warranty.
# 
# ENTERPRISE INTEGRATION TECHNOLOGIES, HEWLETT-PACKARD COMPANY AND NIELS MAYER
# DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED
# WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL ENTERPRISE
# INTEGRATION TECHNOLOGIES, HEWLETT-PACKARD COMPANY OR NIELS MAYER BE LIABLE
# FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER
# RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF
# CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
# CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
#

A random smattering of hints, questions, answers.

------------------------------------------------------------------------------

NOTE ON CLOSING WINDOWS CREATED BY WINTERP EXAMPLE APPLICATIONS:

Many of the example applications (see winterp/examples/*.lsp) don't have
an explicit "quit" or "close" button. If you just want to delete a WINTERP
window without actually terminating the application, you should use your
window manager's "window close" functionality to delete the window. 
All ICCCM-compliant window managers should have such capabilities. I have
run/tested WINTERP successfully with X11r5 twm(1x), and Motif 1.1 or 1.2
mwm(1x). The following instructions apply to those window managers:

	* In mwm(1x) window deletion is accomplished via function "f.kill".
	  In a default mwm(1x) setup, you can close a WINTERP window by
          pulling down the window manager menu in the titlebar and selecting
          the "Close" entry. Alternately, you can type "Alt<Key>F4" (aka
	  (Meta-F4) into the window you want deleted.

	* In twm(1x) the window manager menus "Delete" function
	  (bound by default to f.delete) will close a WINTERP window without
	  terminating the WINTERP process. Beware that the f.kill function
	  bound to "Kill" *WILL* close all your WINTERP windows and
	  terminate the WINTERP process. 

Note that closing WINTERP top-level-windows which are instances of
APPLICATION_SHELL_WIDGET_CLASS *WILL* close all your WINTERP windows and
terminate the WINTERP process. Currently, winterp/examples/w_ctrlpnl.lsp
(the WINTERP Control Panel) is the only example application which has such
behavior.

Note, however, that if the environment variable WINTERP_STANDALONE_APP is
set prior to running WINTERP, then the windows created by the following
examples will cause the WINTERP process to terminate:
	winterp/examples/calendar.lsp,
	winterp/examples/dircmp.lsp, winterp/examples/grep-br.lsp,
	winterp/examples/man-br.lsp, winterp/examples/modem-dialer.lsp,
	winterp/examples/timesheet.lsp, winterp/examples/xbiff.lsp,
	and winterp/examples/tk-challenge/Application.lsp.

The idea behind the WINTERP_STANDALONE_APP environment variable is that you
might want to run the aforementioned applications "standalone" by executing
the following shell command (perhaps in a shell script or from window
manager menu):
   "env WINTERP_STANDALONE_APP=TRUE winterp -init_file grep-br.lsp -no_stdin_serv -no_unix_serv -no_inet_serv -no_init_msgs &"
Doing an mwm(1x) f.kill or twm(1x) f.delete operation on such windows will
both close the window and terminate the WINTERP process.

------------------------------------------------------------------------------

On SunOS, if you get errors like :
|
|    Warning: Widget class VendorShell version mismatch:
|      widget 11004 vs. intrinsics 11003.
|
then you will need to ensure that you are dynamically linking with the
correct X11r4 libXt.a and libX11.a, rather than the outdated ones supplied
by Sun. (In particular, make sure that you are using a libXt.a that has all
18 MIT X consortium patches applied as well as the OSF-supplied patch).

The following message may provide you with the hints for forcing use of the
correct shared libriaries:

| From: dbc@cs.brown.edu (Brook Conner)
| Newsgroups: comp.windows.x
| Subject: Re: Xwebster printing odd warnings
| Message-ID: <69667@brunix.UUCP>
| Date: 23 Mar 91 16:36:40 GMT
| References: <JC.91Mar22022948@condor.bu.edu>
| Sender: news@brunix.UUCP
| Distribution: comp
| Organization: Brown Computer Science Dept.
| Lines: 43
| 
| In article <JC.91Mar22022948@condor.bu.edu>, jc@condor.bu.edu (James Cameron) writes:
| |> 
| |> Running SunOS 4.1.1 on SparcStation 2's and other fun things...  *8-)
| |> 
| |> 
| |> I just got webster and Xwebster up and running (after a bit
| |> of work) and I know seem to be getting some weird warning messages
| |> from Xwebster.  (prelude - I have seen and used Xwebster on another
| |> similiar system.)  Now, the warnings don't *seem* to do anything
| |> at all, they are just a irritation...
| |> 
| |> Warning: Widget class VPanedWindow version mismatch:
| |>   widget 11004 vs. intrinsics 11003.
| [About a billion more such messages deleted (actually one per widget class)]
| |> 
| |> Suggestions anyone???
| |> 
| |> JC
| |> 
| [big sig deleted]
| 
| This happens because there are two versions of Xt running around on
| the SPARC.  The version you should find in $OPENWINHOME/lib and
| the version you should find in /usr/lib/X11 (i.e. MIT X11R4) 
| disagree on a very minor version number. You're right -- these
| messages don't seem to have any earthly effect on the code.
| 
| There are  two ways to fix this problem:
| 1) Carefully set your LD_LIBRARY_PATH so that when you use apps built
| 	using X11R4, you do not have $OPENWIHOME/lib in that path (which
| 	is a bit of a pain if you use both Motif/Athena apps and XView apps,
| 	which I do (since Sun's XGL only seems to be happy under olwm, but I
| 	prefer Motif for my widgets))
| 2) Get your sysadmin to fix it. We fixed it by making the copies of Xt in
| 	$OPENWINHOME/lib be links to the MIT X11R4 versions.  This doesn't
| 	seem to cause any problems, since XView doesn't use Xt.
| 
| Brook
| - -- 
| Brook Conner		| Klacktoveedsedstene
| Brown Computer Graphics	| Fortune sez: Brook's Law -- Adding manpower to a late
| dbc@cs.brown.edu     	|  	software project makes it later
| uunet!brunix!dbc dbc@browncs.bitnet   Box 4013 Brown U Prov RI 02912

------------------------------------------------------------------------------

If you are compiling WINTERP 2.0 with Motif 1.1 and you get errors
at link time complaining about missing _XmTextEnableRedisplay(),
and/or _XmTextDisableRedisplay() (or compiling with Motif 1.0
and are missing XmTextEnableRedisplay() and XmTextDisableRedisplay())
then you should do the following:

	(0) cd winterp/src-server
	(1) delete wc_Text.o,
	(2) make -f Makefile.<???> "USER_DEFINES=               \
		-DOBSOLETE_MOTIF_MISSING_XmTextEnableRedisplay  \
		-DOBSOLETE_MOTIF_MISSING_XmTextDisableRedisplay"

If you're expecting to recompile WINTERP often (e.g. if you're doing a lot
of modifications at the C-source level), then you might consider modifying
src-server/Makefile.???? (the appropriate makefile for your
machine/os/version) by adding the -D defines mentioned in (2) above to
"OSDEP_CFLAGS"...

------------------------------------------------------------------------------
