No subject

them out-of-order.

> That could explain why psp's drawing window isn't cleared when it's
> created, redrawn when it's moved etc., but that using psp's own drawing
> tools on the window *does* work...
These are the two things I'm looking at right now. Wine just does not send
required messages. So there is nothing for app to handle.

> Am I right in thinking that everything in dlls/x11drv/* handles events
> between wine and the rest of the Unix desktop, whilst everything in
> windows/* handles the event structure and clipping between wine
> windows? 
My understanding is x11drv is more low-level interaction with X. Everything in
windows/* belongs to dlls/user. And dlls/user/ is more of a top level type of
things. Bellow all of this is server/ that tracks a number of things, but (as I
understand) doesn't do anything itself. For example: SetWindowPos is defined in
dlls/user/winpos.c, but all it does, is calls X11DRV_SetWindowPos in
dlls/x11drv/winpos.c (for console apps it's somewhere else). Then
X11DRV_SetWindowPos does the whole work itself, using some information from the
server for that.

The problem, as I see it, comes from two places:
1. Wine does not have full implementation of number of things, or it's not
   correct (good enough for apps people where running when they implemented that
   part).
2. Interaction with X and window manager (wm) puts some restrictions to what can
   and can not be done. If certain thing is missing from X then it can't be
   implemented in wine (like some of OpenGL stuff). Same goes for wm (like
   handling of WM_MINIMIZE/WM_MAXIMIZE). It requires closer interaction with wm
   which is not implemented yet.