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.
