X11: Problems with ConfigureNotify events that are received/processed
hallo at michael-kaufmann.ch
Mon Aug 22 07:59:39 CDT 2005
Some other propositions on how to fix this:
1. Don't handle X events in MsgWaitForMultipleObjectsEx, just wait for them.
2. Don't cache the X11 window rectangle and always use XGetGeometry to
get the current window rectangle. That will surely solve the problem,
but also calls like GetClientRect would always need a call to the X
server, making things less efficient.
The first proposal should not be too hard to implement for anyone
familiar with Xlib. I hope somebody can do it.
> Hi all,
> I'm trying to get the dialog boxes of Word 95 working. They often
> appear with the minimal window size (about 70x50 pixels), so they're
> unusable. With KDE's window manager (KWin) this happens very often.
> With Enlightenment and GNOME's window manager (Metacity), it only
> happens from time to time.
> I've looked for the reason, and I think it's very closely related to
> WINE bug 1265 which Duane Clark has tried to fix here:
> That's what's going on (CVS version of WINE, managed window mode):
> 1. Word creates a dialog with an initial position of (0,0) and size
> 0x0 (using CreateWindowEx)
> 2. Word calls SetWindowPos to set the correct dialog position and size
> 3. Word calls SetWindowPos to show the dialog (SWP_SHOWWINDOW)
> 4. The dialog gets the focus, the main window is being deactivated
> 5. In the WM_NCACTIVATE procedure of the main window, Word calls
> GetQueueStatus. WINE will process X events.
> 6. WINE receives a ConfigureEvent for the initial dialog position and
> size (0x0) and saves this to data->whole_rect in
> (7. If you're lucky, WINE also receives a ConfigureEvent for the
> correct dialog position)
> 8. Wine shows the dialog and maps it. It calls X11DRV_set_wm_hints,
> which calls set_size_hints. This procedure uses data->whole_rect as
> the dialog's rectangle. But this stored rectangle is completely wrong
> because WINE has not yet received all ConfigureEvents.
> 9. The window manager has to resize the dialog to the wrong size.
> The best solution would be to process all X events before setting the
> window position in SetWindowPos, but I don't know if that's possible.
> I've tried another approach: WINE should not set the window size hints
> when mapping a window (step 8.). I've attached a patch, but it's not
> 100% correct, because the style of a window (e.g. the WS_THICKFRAME
> style) may be changed by an application using SetWindowLong and
> SetWindowPos (with the SWP_FRAMECHANGED flag).
> WINE doesn't look for the SWP_FRAMECHANGED flag and updates the X11
> window every time if it's visible or gets visible. So if an
> application calls SetWindowPos with the SWP_SHOWWINDOW flag, WINE
> needs to set the size hints because the window has been hidden and its
> style may have been changed.
> What would be the correct fix for this problem? Any ideas?
More information about the wine-devel