(0,0) placement of new windows - sometimes

[Scott Tringali]

Ivan Skytte Jørgensen wrote:

> I have a theory, but need verification by someone who really knows about X and 
> Motif.

Looks like you know plenty!

> When just starting nedit without any files, the initial window is created and 
> the call flow is something like this:
> 
> 1: EditNewFile()
>    ...
> 2:   CreateWindow()
> 3      (presumably XMapWindow in the deep inside Motif)
> 4:     UpdateWMSizeHints()
> 5:       XtVaSetValues()
> 6:       RemovePPositionHint()
> 7:         XGetWMNormalHints()
> 8:         XSetWMNormalHints()
> 
> The window manager gets the MapWindow operation somewhere in (3) redirected to 
> it. If the window manager is a bit slow and first gets around to reparenting 
> the window after (5) but before (8) then the window is at position (0,0) with 
> PPosition hint set, and therefore the window manager places the window at 
> (0,0).

Usually the window is mapped in RealizeWithoutForcingPosition, not at 
#2.  The code you see is a little later on when we recompute some window 
properties based on the font size.

That could be it - an alternate technique I've used is to remove the 
PPosition hint as a popupCallback on the shell.  I'm tempted to try this 
and see.

> The comment in window.c line 2933 is unclear:
>     /* Motif will keep placing this on the shell every time we change it,
>        so it needs to be undone every single time.  This only seems to
>        happen on mult-head dispalys on screens 1 and higher. */
> 
> I don't understand _what_ in Motif sets the program-specified-position bit in 
> the wm_normal_hints property. Is it the XtVaSetValues() call that does this?

It seems that every time you touch a resource on WMShell it recomputes 
the hints and blats them into property.  So, it sees 0 in x and y and 
the turns on PPosition.

> BTW: The "only happens on multi-head" is wrong. It happens on single-head too.

Good to know. It's probably a race that somehow show on your system.