Re: RFC: frame size hints

[Havoc Pennington <hp redhat com>]

On Fri, 2003-12-05 at 11:55, Lubos Lunak wrote:
> 
>  I didn't mean to say the proposal itself is bad (and I didn't say yet it's 
> ok, I was just asking). I rather meant to say that this could possibly have 
> large impact on KWin's code. Currently, I'd have somehow to fake manage on 
> the window, give the internal representation of it to the style, and ask it 
> about the border sizes. And I'd have to perform a noticeable part of the 
> managing process - for example, if the window is too large in some dimension, 
> it'd be maximized in the direction, possibly affecting border sizes. The user 
> can also have size settings stored for this application's windows, so it 
> would have to be applied. And so on, and so on :-/. It could lead to creating 
> a huge hack, or large code changes, possibly both (well, maybe I'm too 
> pesimistic now). But I hope you see why I'm trying to find if it's really 
> necessary.
> 

For metacity Thomas more or less just punted on this; to get exactly the
right frame extents, we would have to create this huge weird code path
that did all the managing work but didn't really manage.

So basically on getting the request for the frame extents, metacity
looks at a couple easy aspects of the window and just estimates. It will
get the frame extents right for normal windows at the current font size
and theme, but maybe not for all the details of the particular window.

Once the window is managed, the frame extents hint is updated to be
accurate. So prior to map the hint is an estimate, and after map it's
accurate. Well, accurate modulo the race condition (you can get
intermediate states where the frame has been resized but the hint not
updated or vice versa, right).

It's not ideal but the breakage is in the implementation, not the
protocol, so we can fix later.

>  Hmm, I'll try to find some other ways. Could e.g. the apps simply guess, map 
> their windows, and reconsider the size after receiving MapNotify? That way, 
> they'll already know the frame sizes. It will possibly flicker a bit, but 
> we're talking about adding a hack, aren't we? And in fact, if they cache the 
> value, they may even often get it right.

All we're really adding with the hint is to get the initial guess right
most of the time, instead of wrong most of the time. Also, the hint lets
the app get the _right_ answer post-map and update accordingly, without
relying on the implementation of the WM frame and doing expensive
XQueryTree() junk.

Havoc