Re: RFC: frame size hints

[Lubos Lunak <l lunak suse cz>]

On Thursday 04 of December 2003 21:04, Thomas Fitzsimmons wrote:
> On Thu, 2003-12-04 at 08:05, Lubos Lunak wrote:
> > On Thursday 04 of December 2003 00:31, Thomas Fitzsimmons wrote:
[snip]
> >  However, the message is something different :(. (Qt doesn't have API for
> > setting size using the frame geometry, it can only read it, and set
> > position using it.) The frame geometry potentionally depends on many
> > things - window type (utility windows get smaller decorations), its size
> > and position (Fitts' Law - maximized windows may be configured to have
> > borders turned off if they are at the screen edge), accessibility
> > settings, and possibly more.
>
> Yes, but the window manager can query the window for that information.
> If the app requests the frame extents after it requests other window
> settings, then the window manager should be able to provide at least a
> fairly accurate guess, even before the window is mapped.  After mapping,
> the client can track its extents by handling PropertyNotify events.
>
> > Moreover,
> > in KWin's case, decorations are plugins, so KWin cannot really guarantee
> > anything. And the API is written in a way that doesn't allow any nice way
> > how to get the sizes from the plugin, before giving it the managed
> > window.
>
> I can imagine.  I encountered similar issues when implementing this in
> Metacity.  I was able to work around them though -- I guess if
> _NET_REQUEST_FRAME_EXTENTS is accepted, KWin's plugin API would have to
> be extended.

 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.

>
> >  That said, I'd probably just respond to the message with something like
> > 'top=10,left=right=bottom=4' all the time - as KWin would often get it
> > wrong anyway, it wouldn't IMHO matter much how much wrong would it be.
> > Which leads me to question: Would (and if yes, how much) the apps break
> > if they simply did this guess themselves?
>
> An AWT Frame treats the window frame dimensions as its insets, so it's
> conceivable that, when the window uses a large title bar font,
> components along the top of an AWT Frame could be obscured by the title
> bar.

 In other words, if I comprehend this, AWT finds out the outer dimensions, and 
creates the layout inside the inner window based on those dimensions?

 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.

-- 
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/