earle@MAHENDO.JPL.NASA.GOV (Greg Earle) (09/25/87)
I've noticed two apparent glitches with NeWS related things, and am wondering if we can get pointers to fixes (NeWS 1.0): (1) Don, I load your `piemenu.ps' in user.ps and everything works fine, but for some reason trying to bring up the little substitute X menu inside an xdemo (like `xload') causes the server to choke, and any subsequent tries yield nothing. Any ideas? (2) If Sam Leffler of Pixar is listening in, it appears that the new `psterm' doesn't set the terminal type in the environment; i.e. if I bring up an h19 (or other) terminal and at the shell prompt do a printenv TERM|TERMCAP I always get `TERM=sun' with `TERMCAP=Mu|sun|...etc.'. I have to explicitly do a `set noglob ; eval `tset -Qs`' in my .cshrc to make sure that each new `psterm' invocation is set properly. Also, there doesn't seem to be any way to have a multiple word label for the psterm window or icon (-fl & -il options). I have a 54x80 Sun terminal menu entry and would like the label to be `54 line sun terminal emulator'; now I have to use underscores instead of spaces to keep it to one word. I tried grouping the words as an argument with "" and '', but it just takes ` "54 ' as the label and tries to exec `line' which of course fails. Apologies for being too ignorant to know how to fix these myself ... -- Greg Earle earle@mahendo.JPL.NASA.GOV S(*CENSORED*)t earle%mahendo@jpl-elroy.ARPA [aka:] Rockwell International earle%mahendo@elroy.JPL.NASA.GOV Seal Beach, CA ...!cit-vax!elroy!jplgodo!mahendo!earle
don@BRILLIG.UMD.EDU.UUCP (09/25/87)
Date: Thu, 24 Sep 87 09:30:51 PDT From: Greg Earle <earle@mahendo.Jpl.Nasa.Gov> I've noticed two apparent glitches with NeWS related things, and am wondering if we can get pointers to fixes (NeWS 1.0): (1) Don, I load your `piemenu.ps' in user.ps and everything works fine, but for some reason trying to bring up the little substitute X menu inside an xdemo (like `xload') causes the server to choke, and any subsequent tries yield nothing. Any ideas? [ ... ] Greg Earle earle@mahendo.JPL.NASA.GOV S(*CENSORED*)t earle%mahendo@jpl-elroy.ARPA [aka:] Rockwell International earle%mahendo@elroy.JPL.NASA.GOV Seal Beach, CA ...!cit-vax!elroy!jplgodo!mahendo!earle Aah, yes. That's because piemenu.ps gets the XLocation and YLocation about which to center the event returned by "currentevent", which depends on the menu having been invoked from an event manager (started with "forkeventmgr"). The event manager leaves the event on the stack for "currentevent" to find later. Unfortunitly, the X10 demo uses the older menu package, and does its own event handling to pop up its menu, instead of using an event manager, so "currentevent" loses. As long as currentcursorlocation returns the present cursor location as opposed to the location of the cursor at the last event delivered, the code has to look at the actual button event to get the correct location to center the menu. This is crucial for mouse-ahead to work properly. (On a related topic, "setcursorlocation" is broken in NeWS 1.0, so the piemenu.ps I've distributed does not "do the right thing" near the screen edge. "The right thing" is to move the cursor by the same offset as the menu must be moved to fit completely on the screen. I'm using "getcursorlocation", adding the offset, and doing a "setcursorlocation" to move cursor by the appropriate offset. Unfortunitly, next time you move the mouse, it jumps back to where it was before!) -Don