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

[Jeff Newmiller]

On Sat, 2 Oct 2004, Jonathan Stickel wrote:

> Bill Kendrick wrote:
> > On Sat, Oct 02, 2004 at 02:06:24PM -0700, Jonathan Stickel wrote:
> > 
> >>Finally got around to trying this, and it does work directly in "simple" 
> >>windows managers (tested in openbox).  However, it doesn't quite work in 
> >>KDE.  Rather than the window coming to the top, the window's entry in 
> >>the taskbar just flashes at me.
> > 
> > 
> > KDE does have an option to 'reduce focus from being lost', e.g. by pop-ups,
> > so the flashing is probably their way of dealing with it.
> > 
> > Try the above again, with that focus option turned off.
> > 
> 
> Yep, you are right.  In KDE 3.3, the option is "Focus stealing 
> prevention level: none|low|medium|high|extreme".  Setting it to "none" 
> allows my code to bring the desired window to the top.
> 
> However, I would like to override this feature in my program so that the 
> window rises to the top no matter what the WM/DE trys to do.  From what 
> I understand, setting the "override-redirect" attribute of the window to 
> "True" should do what I want.  Instead, nothing happens when 
> XRaiseWindow is called, neither in KDE or Openbox.  Any ideas here?

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.

For example, your original query included some implied limitations driving
you to this solution: a) the only way to obtain the screenshot is to push
it to the top, b) that you need a screenshot, c) that the user hasn't
already arranged the windows the way they want them.

a) If you are working with a program for which you have source code, fix
it to produce the screenshot itself.  If you don't, consider a solution
for which you do have source code.  Suddenly you no longer have to worry
about whether the window is on top... the user will have already arranged
it thus.

b) Screenshots are usually a symptom of desire to record the information
rendered onto that screen.  Consider re-rendering for the print engine to
obtain better resolution/aspect ratio, or render to an accessible data
format (xml/abiword file/text/latex/whatever).  Note that in many cases
you may already be able to read their data format and render it yourself
independent of a proprietary program.

c) If the user is convinced this is the solution they want, make them
adjust settings or arrange the windows themselves (timers may be necessary
to implement the latter).

A solution that moves or blocks movement of windows without the user's
explicit involvement is a kludge, and should be treated as such... kludges
need to be documented and eventually eliminated, not enshrined as
userfriendly "helper applications" whose intent is something other than
window management like taking screenshots.

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