On Mon, 4 Oct 2004, Jonathan Stickel wrote: > Jeff Newmiller wrote: > > I detest programs designed to behave this way... from "helpful" cpu status > > displays to "Did you really want to quit this program?" dialog boxes to > > "Your Windows resources are running low" to "We are backing up your > > data... please wait" dialog boxes... they all suffer from either hubris or > > programmers who couldn't handle multitasking. Please stop trying to take > > control away from the users ... there has to be a way to avoid this > > unfriendly behavior in your software ... be creative and find it. > > > <snip> > > I appreciate your comments. Let me explain a little bit more about my > problem. I am helping with a 3D visualization add-on (octaviz, built on > VTK) for a numerical math package (octave). Octave typically runs as a > command-line interpreter in a shell window. Graphing commands (and now > visualization commands) generate new windows that contain > graphs/graphics. 2D plots can be exported in some vectorized format, of > course. The 3D visualizations, however, are complex, opengl rendered > objects with mouse interaction to rotate, zoom, etc. Image "snapshots" > of the windows are often the only way to get a desired export of the > visualization.
No way to extract the user-entered orientation data and re-render offscreen? [1][2] If you really aren't interested in the user's geometry input (automation of image generation) then offscreen solutions should be fairly easy. If you are, then user interaction should include raising the necessary window. > There are functions in VTK to do just this, but the > rendered window MUST be on top to work; otherwise, it exports whatever > screen image is over the top of the VTK window. And yes, I do consider > this to be a feature problem in VTK, but I do not have the technical > expertise nor time to make changes to VTK. Time and expertise... perpetual problems. > So... a quick and easy fix for me is to force the window on top before > my export command saves the window as an image. I did spend all weekend > looking through Xlib programming docs to see if I could get around this > some way, for example by keeping the window data in memory when it is > covered up. Another option is off-screen rendering, but that path isn't > short either. An even quicker and easier fix would be to require that the user insure that the view window is on top, or at least not overlapped, before proceeding to extract image data from it. > If anyone has further suggestions, I would be happy to hear them. For > now I /try/ to bring the window to the top and have a warning in the > user docs about this. Hook an event off the vtk window that calls you back when the user clicks on a button to generate the image. [3] At the appropriate place in your octave routine, give the user an option to go print the window. Most users will raise the window in order to interact with it... if not, they can be trained to do so. When your code recognizes that this has been done, it can proceed to use the "buggy" vtk output routines... or proceed without saving when it directly receives appropriate keyboard input in the octave window. At some point, when the VTK code is fixed, or you figure out an offscreen solution, you or someone else interested in getting around the user input can fix the problem. --- [1] http://public.kitware.com/pipermail/vtkusers/2004-August/075593.html [2] http://public.kitware.com/pipermail/vtkusers/2004-August/075602.html [3] I am lead to believe this is possible by the description on the web page http://wissrech.iam.uni-bonn.de/research/projects/NaSt3DGP/documentation/userguide/node33.html --------------------------------------------------------------------------- Jeff Newmiller The ..... ..... Go Live... DCN:<[EMAIL PROTECTED]> Basics: ##.#. ##.#. Live Go... Live: OO#.. Dead: OO#.. Playing Research Engineer (Solar/Batteries O.O#. #.O#. with /Software/Embedded Controllers) .OO#. .OO#. rocks...2k --------------------------------------------------------------------------- _______________________________________________ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
