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

[Jeff Newmiller]

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:<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
---------------------------------------------------------------------------