root@sgzh.uucp (Bruno Pape) (03/22/90)
Wow Dave, I liked the history lesson. It was very good. I kinda knew that ginit would blow away the screen, but I figured John would be able to take care of things once he saw that is was just that the graphics needed to be initialized. Old habits like ginit() never go away, unless they quit working. Bruno -- Good organization is only screwed up by reality. If its published, tell me by whom, otherwise it's mine.
robert@texas.esd.sgi.com (Robert Skinner) (03/24/90)
In article <1990Mar22.142346.7801@sgzh.uucp>, root@sgzh.uucp (Bruno Pape) writes: > > Old habits like ginit() never go away, unless they quit working. ^^^^ ^^^^^^^ and you know what many customers say when something stops working: "HEY, YOU BROKE IT!" "But that old ginit() doesn't really apply anymore." "IT DOESN'T WORK ANYMORE!" "But if you use this whizzy new thing it works much better and you get all these new features." "YOU BROKE IT!" ... such is life Robert Skinner robert@sgi.com "Congress is not the sole suppository of wisdom." Rep. Bill Schuette (R-MI)
root@sgzh.uucp (Bruno Pape) (03/26/90)
In article <5662@odin.corp.sgi.com> robert@sgi.com writes: > >In article <1990Mar22.142346.7801@sgzh.uucp>, root@sgzh.uucp (Bruno >Pape) writes: >> >> Old habits like ginit() never go away, unless they quit working. > ^^^^ ^^^^^^^ >and you know what many customers say when something stops working: > > "HEY, YOU BROKE IT!" > >"But that old ginit() doesn't really apply anymore." > > "IT DOESN'T WORK ANYMORE!" > >"But if you use this whizzy new thing it works much better and you >get all these new features." > > "YOU BROKE IT!" > I did not mean to imply that you should start breaking things. PLEASE NO, NOT THAT. I enjoy programming my 4D like a 2400 just as much as the next guy. It was just my way of saying that some of the older techniques will be my first choice until they quit working. But lets not rush it along. Thanks, Bruno
karron@KARRON.MED.NYU.EDU (11/20/90)
This is my observation of some window behavior that should be fixed. It is not a problem, but if you guys did this in the window system, then we applications people would not have to do odd things or add code to make up for these properties. 1) Killing secondary windows spawned from a noport() window. If you hit the zap icon in the upper right corner of the 4sight standard window, the actual parent process that spawned the window will not be killed until you kill the parent window. My problem is that my main loop and process is a noport window, and the other windows are all child windows. There is no way to kill the parent process from the zap icons if the parent process forks. You have to do a killall or kill. The solution should be that if you kill the last drawn window, in any order, then the parent process should be killed, even if it does not have a window. I would like not to have an exit button on my window widgits. If I could reliably expect the zap icon to do it for me, that would make my application menus that much less cluttered with buttons. 2) REDRAW event should be queued when the window opens. I queue a REDRAW event, and I know the size of my windows I setup so there is no reason to deal with a resized window on winopen. It would eliminate a line of application code if I could expect an initial window opening to queue a REDRAW. Otherwise, I am relatively content. You might want to keep this in mind for the next rewrite of 4Sight in X. +-----------------------------------------------------------------------------+ | karron@nyu.edu (mail alias that will always find me) | | Dan Karron | | . . . . . . . . . . . . . . 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 \**\__________________________________________ | | Please Note : Soon to move to dan@karron.med.nyu.edu 128.122.135.3 (Nov 1 )| +-----------------------------------------------------------------------------+
merritt@iris613.gsfc.nasa.gov (John H Merritt) (11/20/90)
In article <9011200320.AA26948@karron.med.nyu.edu> karron%CMCL2.NYU.EDU@cunyvm.cuny.edu writes: > >This is my observation of some window behavior that should be fixed. Then, open your eyes! I would not like to see any of the mods you mention implimented as the default. It is trivial for you to write a wrapping library of functions to effect >2) REDRAW event should be queued when the window opens. I queue a REDRAW your suggestions. For example (in close C), int my_winopen(char *name) { id =winopen(name); qdevice(REDRAW); return(id); } >It is not a problem, but if you guys did this in the window system, then >we applications people would not have to do odd things or >add code to make up for these properties. > >1) Killing secondary windows spawned from a noport() window. > >If you hit the zap icon in the upper right corner of the 4sight standard >window, the actual parent process that spawned the window will not be killed >until you kill the parent window. A similiar *accounting* of windows can be kept if you want the *last* opened window to ZAP everything, and it can be done with a few lines of code which records the PID's of all the spawned programs (windows) and sends a kill to every process when the last window dies. Adding special cases to an already nice implimentation will complicate it; it will die under its own weight. John H. Merritt --> merritt@iris613.gsfc.nasa.gov Applied Research Corporation at NASA/GSFC "Yesterday I knew nothing, today I know that."
msc@ramoth.esd.sgi.com (Mark Callow) (11/27/90)
In article <3961@dftsrv.gsfc.nasa.gov>, merritt@iris613.gsfc.nasa.gov (John H Merritt) writes: |> In article <9011200320.AA26948@karron.med.nyu.edu> karron%CMCL2.NYU.EDU@cunyvm.cuny.edu writes: |> >2) REDRAW event should be queued when the window opens. I queue a REDRAW |> |> int my_winopen(char *name) |> { |> id =winopen(name); |> qdevice(REDRAW); |> return(id); |> } This wrapper is completely unnecessary. winopen already does a qdevice(REDRAW). The man page even tells you so. I don't think Karron is that dumb (you do RTFM don't you Dan). I think what he's asking for is for a REDRAW event to be put in the queue when the window is first mapped. I happen to think it's a good idea but it's never likely to happen because of the compatibility problems it would cause. Besides it's not a big deal to type the statement qenter(REDRAW); I tried to reply privately to Karron but my mail was bounced somewhere. I was curious to know why he wanted a main process and loop with a noport() window. 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. -- From the TARDIS of Mark Callow msc@ramoth.sgi.com, ...{ames,decwrl}!sgi!msc "Spirits of genius are always opposed by mediocre minds" - Albert Einstein