[comp.windows.x] "olwm" problem

marbru@attc.UUCP (Martin Brunecky) (03/21/91)

  I am in a desparate need for a help.

  The trouble is "olwm" on SPARCstation, OPEN WINDOWS 2.0.
  The client  is Motif 1.0.3 based application which tries to:

  - popdown an application shell
  - set values for x,y,width,height
  - pop the shell up hoping for some consistent behavior.

  Unfortunatelly, the behavior seems to be completely random. In most
  instances, running under dbx makes a BIG difference, in particular
  how long I look at each line of my code significantly impacts the
  result.

  I got an advice that "olwm" pays attention to WM_NORMAL_HINTS property,
  looking at PPosition, PSize, USPosition, USSize (and honoring those).
  It has been suggesteted that those hints are not set up properly
  before mapping the window.

  So I went in, and before I do my XtPopup (map window), I set the hints
  properly. Then I Xsync. Then I wait for exposure, kicking the XNewsServer
  in it's lazy but by calling XSync (without XSync it took 15 seconds
  to popup a shell without any other X protocol requests). 
  Now, along with exposure I do get ConfigureNotify event - or two.
  Depending on how fast I stepped through my XSync's, the ConfigureNotify
  either contains the expected geometry, or something in between the
  expected result and the previous geometry (before I popped down this shell).
  After that, I usually end up with some random size of the shell, and
  often the client side convinced that it's request has been honored, but
  "olwm" reparenting window being quite different.

  If the ConfigureNotify is "expected", the xprop reveals that my size
  hints are as I specified. If the ConfigureNotify is bogus, *someone*
  has changed (or ignored my XSetSizeHints) so that xprop reveals
  bogus values.

  ANY IDEAS ?  ANY HELP ?

  One more observation. The XNeWs server has some problem. Often it refuses
  to communicate with clients *until* the mouse moves (gets mouse input).
  I had a similar problem with my Digitizer Server (derived from the MIT 
  XServer), and the problem was that sometimes the server asked for the
  mouse input, but there was nothing there and the server blocked on a
  trying to get that non-existent input.
  Can this server's "laziness" have something to do with the problem ?

Please, don't try to reply to marbru@auto-trol.com, someone is witholding
my mail again. Either call me, or mail to ...sunpeaks!auto-trol!marbru.

-- 
=*= Opinions presented here are solely of my own and not those of Auto-trol =*=
Martin Brunecky                           {...}sunpeaks!auto-trol!marbru
(303) 252-2499                        (sometimes also:  marbru@auto-trol.COM )
Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404