winoptions and xterm

[Scot H. <sc...@ap...>]

Howdy,


My previous docking question was resolved with the geometry option
pointed out by Craig Callendar.  I added "grp0.geometry: 985x719+0+0" to
winoptions and it lined up just fine and started in the upper-left.  I
got the precise geometry by trial and error/tuning.

Now I'm having an issue where the main application, a window running
under 4Js' fglX11d display manager on the ICE desktop, calls 'xterm -e
(application)'.  The xterm window opens and starts the character-based
application, and it gets the focus, but it does not come to the
foreground.  Further, once the xterm opens, _if_ I can see it behind the
larger 4Js window, click on the xterm does not bring it forward.  I have
to alt-tab two times, first to focus on the 4Js app and then to focus on
the xterm, which then comes to the front.  I cannot do this in one
alt-tab sequence, either.  I have to alt-tab, release, then alt-tab back
to the xterm, which then pops forward.

In this case there are only two apps on the desktop: the 4Js application
and the xterm.  I played with layer and focus settings for both apps,
checked xprop settings to make sure my changes were taking and to check
the states of the windows, and everything looked fine.  I've got the
right details in winoptions for the class (XTerm), though I've tried
both the class and the name (xterm, as reported by xprop) and the combo
(class.name.option, or XTerm.xterm.layer).

I notice changes based on what I've done, and I know "XTerm.(option)"
works as I've successfully gotten rid of the control bar (don't want
users clicking to close this application).  Nothing I do, however,
forces the xterm to the foreground.

Where else can I look?  This is drivin' us nuts!  Well, me, and others,
and maybe not nuts so much as wishing we had an answer.


Ciao!
sh

-- 
Scot Harkins (KA5KDU)
Systems Engineer
Apropos Retail Management Systems
sc...@ap...
http://www.aproposretail.com