On Sat, 26 Jan 2002, Ori Pessach wrote:
> I found that the game's main window simply wasn't managed. The game opens a > window that covers the entire screen, and doesn't have a caption. > is_window_managed(), in dlls/x11drv/window.c therefore returns FALSE for that > window, and (I'm guessing here) since Wine is running in managed mode, it > manages that window poorly. Switching desktops in KDE doesn't remove the > window from the screen, it's impossible to get any window to display on top > of the game window, and in general, several functions in x11drv/winpos.c > behave badly when Wine has a mix of managed and unmanaged windows. I know. Look at the discussions I had with Alexandre trying to fix this, http://www.winehq.com/hypermail/wine-devel/2002/01/0416.html (my patch is at http://www.winehq.com/hypermail/wine-patches/2002/01/0135.html) > Changing is_window_managed()'s default return value to TRUE makes the game > behave much better, but not perfectly. The KDE panel stays on top of the game > window - it can be hidden away, but Windows handles this differently, letting > the game window obscure the task bar. I'm inclined to call this a KDE > problem, rather than a Wine problem. It also happens in Gnome if you enable the gnome panel's "keep-on-top" option. It may be possible to add an additional window manager hint for WS_EX_TOPMOST windows that will make that window stay on top of those panels. > Also, I don't know whether the tests in is_window_managed() cover all the > cases in which a window should stay unmanaged. Right now, is_window_managed() > tests for child windows and tool windows, and returns FALSE for those > windows. Are there any other types of windows that shouldn't be managed? Yes, Alexandre mentions popup menus and tooltips. Perhaps a chart could be made, so that it is possible to work out what conditions should be used to decide whether to make a window managed...