karron@KARRON.MED.NYU.EDU ("Dan Karron ") (11/27/90)
I don't know who said what, but: >I tried to reply privately to Karron but my mail was bounced somewhere. Sorry, I had a temporary config error that caused my machine to lose track of who it was. All is fixed. I maintain a mail alias on nyu.edu that is reachable from everywhere. See my signature. >I was curious to know why he wanted a main process and loop with a noport() >window. The reason is this: I have a program that does nothing but draw an unknown number of panel widgits. The main loop calls a subroutine that expects the window manager initalized. I don't do any drawing in the main loop, just open widgits. The code operates on an Arena, but most of the component program does not do any drawing of its own. I will send you code. I want to test the code so that I don't need a noport() window. You started me thinking that that may not be required. (Daa...) >noport() was intended for things like scrsave and loading the colormaps. It's >basically a hack because the only way to initialize the Graphics Library and >get access to the graphics hardware is through winopen which has the >horrid (in some circumstances) side effect of creating and mapping a window. >There will be another way to initialize the GL in the next major software >release. > Could you clue me in ? >I don't think Karron is that dumb (you do RTFM don't you Dan). You don't know how dumb I am, but a large part of my waking effort it to keep that a secret from others. Thanks for the left hand complement. You should also not try to hide too much behind man pages that have too many inconsistent exclusions and conditions attached to a subroutine's property. The first thing I forget is the hooks. >I think what he's asking for is for a REDRAW event to be put >in the queue when the window is first mapped. Precisely. You read my mind, as my words were not clear. >I happen to think it's a good >idea but it's never likely to happen because of the compatibility problems >it would cause. I think it is a good idea too. Some people unroll one loop of the redraw cycle as a prefix to the input queue loop. Good design should make for a simple application program. Why not squeeze multiple adjacent REDRAW tokens in the input queue ? I may write code to do just that. A string of REDRAW's received during a long draw should be collapsed into one token. Currently, I want to get rid of anoying redraw's queued by an impatient user. An inputchange during a draw cycle should break the draw cycle, and return for another start at a draw cycle, otherwise you have to wait while your broken window completes its redraw before it can be fixed in the next redraw. >Besides it's not a big deal to type the statement > > qenter(REDRAW); > Just this one statment is an elegant solution to a messy problem, if you don't happen to know the secret invocation. The best programs are short, subtle, and simple. With a little help from the operating system, they can be very short. I would like to not have my panels cluttered up with exit/quit buttons. I would like to depend on the operating system "zap" button. One of the nice things about unix is that you can fix things that don't seem right just by writing more code. One of the best things about info-iris or comp.sci.sgi is that guys like you are listening. Between us, it should be possible to eliminate baggage code and permit clean, clear, and beautiful application code. Cheers! +-----------------------------------------------------------------------------+ | karron@nyu.edu (E-mail alias that will always find me) | | * Dan Karron, Research Associate | | . . . . . . . . . . . . . . * New York University Medical Center | | 560 First Avenue \*\ Pager <1> (212) 397 9330 | | New York, New York 10016 \**\ <2> 10896 <3> <your-number-here> | | (212) 340 5210 \***\_________________________________________ | | Main machine: karron.med.nyu.edu (128.122.135.3) IRIS 85GT | +-----------------------------------------------------------------------------+