Re: frame size hints - for Wine

[Dominik Vogt <dominik vogt gmx de>]

On Wed, Jan 29, 2003 at 09:15:52AM +0900, Mike McCormack wrote:
> 
> Well, Wine is not really an application, it is an API translation 
> library, so it is bound by rules of the Win32 API.  Win32's CreateWindow 
> supplies the coordinates of the frame, not the client area.
> 
> Ideally, I'd like to be able to ask the WM "If I created a window whose 
> frame was at x,y with w pixels hight, and h wide, with properties X,Y 
> and Z, where would the client area end up?"

Well, what exactly would you plan to do with that information?  We
once tried to compile a list of all possible applications.  As far
as I remember, the main points were

 * Initial window placement.
 * Resizing windows to full screen size with or without
   decorations.
 * Aligning windows to other windows.

I mad a proposal a while ago that was able to provide these
features without any client knowledge about it's actual frame
geometry, but I have to acknowledge that it probably was too
complicated and too confusing.

> Wine can be hacked to work right most of the time with either a hint or 
> a "place frame at" protocol.  "Place frame at" seems similar to 
> requesting maximization via the _NET_WM_STATE request already supported 
> by EWMH, however Wine has some trouble with that at the moment.
> 
> Dominik Vogt wrote:
> 
> >No, I think that would be a very bad idea.  First, applications
> >should not have to worry about their decorations.  Second, when
> >the application finds out the expected size of the decorations,
> >the information may already be obsolete.  And third, the window
> >manager may not be able to find out the actual values before the
> >window becomes mapped.  This may depend on many properties of the
> >window which the WM can not find out beforehand, for example the
> >MWM hints, whether the window is transient for a valid, mapped
> >third window, its name, class, resource or icon name, whether the
> >window is mapped as an icon (and the WM allows icons at all), the
> >window group it belongs to, the position of the pointer, the
> >screen it is mapped on, and so on.
> >
> >All these problems can be avoided by a "place frame at" protocol.

Bye

Dominik ^_^  ^_^