Re: frame size hints - for Wine

[Havoc Pennington <hp redhat com>]

On Wed, Jan 29, 2003 at 04:11:05AM +0900, Mike McCormack wrote: 
> The biggest problem is that we need to know this before the window is 
> mapped, so that we can send the application a WM_WINDOWPOSCHANGING 
> message with its new size :-(

This is pretty tricky, because the frame size is dependent on quite a
few properties of the window - its geometry hints (resizable or no),
and its semantic type, at minimum, I would say. In theory it's
dependent on *any* property of the window-to-be-mapped, but we could
safely ignore that I'm guessing.

I do think we should provide a good way for WINE to work here, because
the win32 API isn't really negotiable, and a WINE that uses managed
windows is a whole lot better than the override redirect
draw-its-own-frames mode, even if there are some corner cases we can't
quite get perfect.

Is it OK with you to make a round-trip query to the WM to get this
information?

If you can live with the latency, we could have a message to the WM
that gives the window ID of the unmapped window. The WM would then
query some properties off the window (another round trip), and return
an estimated frame size which you could use to determine the size of
your window.

So you would set up your window with all its hints so it's ready to
map; send the query; wait for the reply; resize the window and map it.

> Because we have no reliable way to determine the frame size, Wine 
> currently has problems when an application maximizes a window, or 
> creates a window the size of the screen... the client area may be 
> incorrectly sized, or the borders of the window may not be visible.

For maximization, you should try to find a way to use
_NET_WM_STATE_MAXIMIZED - i.e. it should not be done by having the app
resize itself larger.

I'd be willing to work with you to prototype a working setup with
metacity as _METACITY_foo hints, if you want to do that, and then we
could come back to the list with a tested solution.

Havoc