GUI-unfriendliness (was Re: [vox-tech] "bring to front" X-window command)

[Richard Harke]

I have worked a little with VTK and I know that it is built on OpenGL
VTK gives you a couple of options. The default is that VTK  just creates
a single window for the 3D display and the actions of the mouse are
predetermined, rotate, pan and zoom> If you want to have more elaborate
control you can integrate with a windowing system where the 3D window 
will be a child window in the system and other windows can offer additional
functionality. But the default is Motif, or least it was the last time I 
worked with it. I did get a Qt version from somewhere in France and
did get that working. In any case you may want to look at glReadBuffer and
glReadPixels in the OpenGL manual.

Richard Harke

On Monday 04 October 2004 18:09, Jeff Newmiller wrote:
 > > 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/us
>erguide/node33.html
>
> ---------------------------------------------------------------------------
> Jeff Newmiller                        The     .....       .....  Go Live...
> DCN:<jdnewmil at dcn.davis.ca.us>        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
> vox-tech at lists.lugod.org
> http://lists.lugod.org/mailman/listinfo/vox-tech