Re: RFC: frame size hints



On Friday 05 of December 2003 20:07, Havoc Pennington wrote:
> 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.

 I'm not discussing the hint, I already said that one is fine with me. What I 
don't like much is the pre-map message. You yourself said above that Metacity 
can get it wrong too. Which means, the apps will have to check and possibly 
either adjust or live with that anyway. What would be the point of adding 
something broken then? What's the difference between
- WM gives the app possibly wrong data, after map the app checks and adjusts 
or lives with that
- app itself chooses some possibly wrong data (guesses, remembers old right 
values, whatever), after map the app checks and adjusts or lives with that

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l lunak suse cz , l lunak kde org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]