That's try this patch:
http://www.winehq.com/hypermail/wine-patches/2005/05/0207.html
Wednesday, May 11, 2005, 9:17:31 AM, you wrote:
> On Fri, 2005-05-06 at 09:50 -0600, Vitaliy Margolen wrote:
>> You know, it could be one more place then. Native does RedrawWindow when
>> focus
>> changes. But not always. As soon as I figure out when we need to redraw and
>> when
>> we don't, I'll send you a patch to try.
> The more I think about this, the more it makes sense that the X11 side
> of things is functioning correctly.
Not really. I have found few things that are not. Some are "wontfix" some are
pain to fix.
> I can't find any wine docs (yet) that describe message flow for the
> windowing system, but I suspect the following (someone shout if I'm
> definitely right or wrong on this!):
> Paint Shop Pro will be one of those classes of apps that looks after its
> own drawing windows, and expects the system to pass *all* window related
> messages for its drawing window(s) to the app itself, rather than wine
> trapping and handling some of them.
This is up to any app to do. All messages are sent to app in a first place. Then
app decides if it will handle the massage or pass it default handler.
> I suspect this is what got screwed up as of the 20050111 release - wine
> is probably either handling *some* types of window event when it
> shouldn't, or at the very least isn't passing them on to the application
> so that the app can respond as it sees fit.
>From what I seen, I could say that wine doesn't send enough messages or sends
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.
