Window management thoughts

Mike Hearn mh at codeweavers.com
Tue Apr 6 10:07:58 CDT 2004


So, me and Mike have been discussing some ideas for window management in
Wine. Currently it hasn't turned into code, but I thought I'd write up
what our thoughts were so others could comment and maybe be inspired to
write patches.

The problem:

Currently Wine decides whether to make a window managed or not based on a
series of heuristics, in is_window_toplevel in dlls/x11drv/window.c

Unfortunately these heuristics are frequently wrong, as they have only
limited information to work with (window styles, mostly). In CrossOver,
is_window_toplevel is easily the most hacked function in the entire
codebase. This manifests itself in a variety of ways:

* Windows are marked unmanaged when they shouldn't be. For instance, see
WinAmp, Trillian, the Counter-Strike CD Key screen etc: there are tons of
examples of this problem. This at best means the window is "nailed" to the
screen, at worst it makes the program unusable.

* The classic "my game starts but I can't type" problem where keyboard
input goes to the terminal instead of the window, due to the lack of focus
management in unmanaged windows.

* Some programs display splash screens and then pop up errors or question
dialogs underneath them. Unmanaged windows are always-on-top -> you cannot
get to the underlying managed window and the app appears to hang.

* Fullscreen windows are really hard to do properly because they must be
managed to work correctly in KDE/GNOME.

We currently make certain windows unmanaged typically because we need to
control their position or rendering with a high degree of accuracy.
Unfortunately some X window managers ignore positioning hints, even when
we ask them not to. There is no way to make things like menus and tooltips
work correctly with these WMs, so we take the window out of the usual
window management mechanism entirely.

Unfortunately due to the design of the win32 API there is no simple way to
tell the difference between a large menu and the Trillian main window. We
could mark our own menus specially to make them unmanaged and have
everything else be managed, but we then run into problems with programs
that draw their own menus and tooltips, of which there are a truly
shocking number.

So what is a possible solution?

Well, one way forward is to implement another mode, in which Wine makes
all windows managed and uses a variety of WM hints to get the desired
behaviour. For instance, the PPosition flag asks the WM to place the
window where the application requests it to. Some WMs respect this, others
do not, in yet others it's a toggleable option. For people with WMs that
meet the requirements of Wine all windows could be made managed, and for
people that don't use such WMs the old way can still be used.

IIRC it's possible to ask the WM for identification which means this
setting could be largely autodetected by having blacklists of WMs to use
the old mode for (or vice-versa). 

Unfortunately there's no way to know how well this approach would work, or
even if it would work at all, short of trying it.

thanks -mike





More information about the wine-devel mailing list