Path: utzoo!attcan!uunet!zaphod.mps.ohio-state.edu!usc!apple!limbo!taylor
From: taylor@limbo.Intuitive.Com (Dave Taylor)
Newsgroups: comp.sys.hp
Subject: Re: standards for windowing software?
Message-ID: <1393@limbo.Intuitive.Com>
Date: 24 Oct 90 17:21:46 GMT
References: <1990Oct20.123109.7287@cs.dal.ca> <7540063@hpfcbig.SDE.HP.COM>
Reply-To: taylor@limbo.Intuitive.Com (Dave Taylor)
Organization: Intuitive Systems, Mountain View, CA: +1 (415) 966-1151
Lines: 96

Bill Silvert wrote:

> Working with VUE I discovered that programs like vi and more assume a 
> 24x80 window and won't adjust to work with any other size (for example, 
> with a longer window they use only the top 24 lines).

Lots of people since have talked about how to use the X11 "resize"
command before invoking the editor windows, et. al. but I think they've
missed the original problem that Bill was talking about; editor windows
*launched from VUE* are too small.  Vi cannot resize dynamically once
it's started up (as far as I know), so once the window is there, he's
stuck with it at the wrong size.

He can have Vi pop up as a generic shell window (e.g. a solution like:
set EDITOR to "csh", then when the editor is launched from the VUE
environment immediately go into the (interactive) window, drag it to 
the size you desire, then use "resize" and "vi" commands to get it to
what you want (actually, "resize ; exec vi $*" or similar)).  The
problem with that is that he doesn't then have editor windows from
VUE, really, and has then lost out on one of the important features
of the VUE environment itself.

Another solution that might be interesting to try would be to fiddle
with the EDITOR value to see if you couldn't get something like 
"EDITOR='=80x40 vi'" to work (that is, exploit how VUE is invoking
the editor in an Xterm window by spoofing some additional command
line parameters)  (retrospectively that probably wouldn't be very
easy because VUE probably calls something like "xterm -e $EDITOR")

Ultimately, there should be some easily user-accessible script or
command mapping scheme that has an entry like:

	EDIT_WINDOW
	   ICON = EDIT_WINDOW_ICON
	   CMD  = xterm -e $EDITOR #1
	END

where "#1" is expanded to the name of the file in question, and EDITOR
is expanded to the environment variable as appropriate (or "vi" as a
default).  If that were present, then users could easily go into the
file (or have a locally, user specific, modified version of their own)
and change it, say, to:

	EDIT_WINDOW
	   ICON = EDIT_WINDOW_ICON
	   CMD  = xterm =80x40 -e $EDITOR #1
	END

It's worth noting that both of major the third party graphical user
environments, X.desktop and Looking Glass, offer features of this
nature (and both are more sophisticated than VUE too, in my view)
(uh, pardon that pun!).  In fact, in Looking Glass, for example,
one could have an editor icon that actually had a default window
size, but, with a CONTROL-button sequence, would actually pop up
a list of different size windows that the user could then choose
from with a script similar to:

	DEFINE TYPE EDIT_ICON
	  ICON	EDIT_WINDOW_ICON
		
	  COMMAND "xterm =80x40 -e $EDITOR #f"
	  COMMAND_DESCRIPTION
		"Edit the file, use an 80x40 window"

	  COMMAND "xterm =80x50 -e $EDITOR #f"
	  COMMAND_DESCRIPTION
		"Edit the file, use an 80x50 window"

	  COMMAND "xterm =80x25 -e $EDITOR #f"
	  COMMAND_DESCRIPTION
		"Edit the file, use an 80x25 window"
	END	

Users would then see a menu of choices:

	Edit the file, use an 80x40 window
	Edit the file, use an 80x50 window
	Edit the file, use an 80x25 window

which they could -- each time -- choose from.  

* * * * *

  I strongly believe that HP-UX should include the transmission and 
  interception of the SIGWINCH command, which indicates to the
  programs that receive it that the window has been resized.  
  They then simply query the system about the new size and reconfig
  themselves.  Not massively difficult.

* * * * *

						-- Dave Taylor
Intuitive Systems
Mountain View, California

taylor@limbo.intuitive.com    or   {uunet!}{decwrl,apple}!limbo!taylor