Hi Gerard,
Unfortunately, this patch does break something : Enlightenment places
managed windows wherever it wants regardless of the parameters we give to
XCreateWindow.
However, it seems to us that this problem might be related to the
EVENT_Synchronize recursion problem.
> What happens is the following :
> - the app call SetWindowPos on the window to position it at 129,244
> - it then call again SetWindowPos to position it at 0,0
> - it shows it. The MapWindow call generates a ConfigureNotify with
> 129,244 as coordinates :-/, and X code calls back SetWindowPos
> (in EVENT_ConfigureNotify)
We should normally get two ConfigureNotify events. One for (129,244) and
another one for (0,0). But because SetWindowPos is called recursively, we
end up processing the second inside of the first one, so the final position
we keep is (129,244).
There is a simple way to test that idea, you could try removing the two
EVENT_Synchronize calls in SetWindowPos and check if the problem reoccurs.
If not, then correctly fixing this problem won't be an easy task (rewriting
SetWindowPos,...).
On the other side, badly positioned managed windows shoudn't be a big issue
in the WineHQ tree, a lot of windows are still unmanaged and not affecrted
by position hints ( unlike the CorelTree where all tool windows are managed,
so we really need position hints). Therefore our original patch could be
reverted if necessary.
Jean-Claude Batista &
Louis-Philippe Gagnon.
Macadamian Technologies.
