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.