Re: RFC: frame size hints

[Thomas Fitzsimmons <fitzsim redhat com>]

On Thu, 2003-12-04 at 08:05, Lubos Lunak wrote:
> On Thursday 04 of December 2003 00:31, Thomas Fitzsimmons wrote:
> > Hello,
> >
> > This is a proposal for a new application window property,
> > _NET_FRAME_EXTENTS, and a new root window message,
> > _NET_REQUEST_FRAME_EXTENTS.  These additions allow a client to know the
> > extents of its window frame.
> >
> > Havoc described the need for such extensions in this message:
> >
> > http://mail.gnome.org/archives/wm-spec-list/2002-November/msg00051.html
> >
> > and proposed an implementation here:
> >
> > http://mail.gnome.org/archives/wm-spec-list/2003-January/msg00048.html
> >
> > I've implemented this extension for Metacity and have used it to
> > implement GNU Classpath's java.awt.Window API.
> >
> > Comments?
> 

Hi Lubos,

>  KDE actually has property announcing the frame widths, it's called 
> _KDE_NET_WM_FRAME_STRUT. Qt has some API that allows to position windows 
> using the frame geometry, rather than the window geometry itself, and it uses 
> this property (otherwise it tries to walk up the window hiearchy and guess). 
> I don't have a problem with this, it would mean just adding an alias for the 
> new name.
> 

Great!

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

>  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.  A less severe consequence of always returning the same extents is
that calling setSize on an AWT Frame does not produce the expected
dimensions.

I realize that the AWT's API is different from most other toolkits in
its treatment of window sizing, but there are AWT and Swing apps out
there already that are expecting this behaviour.  And from previous
discussions it seems that the ability to set the size of a bordered
window would be useful to other API implementors as well (WINE, SWT).

If we don't standardize this, then the AWT (and all other programs that
use similar APIs) will behave differently when running under different
window managers, which is not ideal.

> [snip]
> > 	<sect2><title>_NET_FRAME_EXTENTS</title>
> > 	<programlisting><![CDATA[
> > _NET_FRAME_EXTENTS, left, right, top, bottom, CARDINAL[4]/32
> > ]]></programlisting>
> > 	<para>
> > The window manager should set _NET_FRAME_EXTENTS to the extents of the
> > window's frame.  A window's frame extents are defined as follows:
> > 	</para>
> > 	<para>
> > left = x coordinate of window's left edge, relative to its frame's left
> > edge
> > right = frame_width - window_width - left
> > top = y coordinate of window's top edge, relative to its frame's top
> > edge
> > bottom = frame_height - window_height - top
> 
>  I think it would be much simpler to say just 'left,right,top,bottom are 
> widths of the respective borders added by the window manager'.

Yup, I agree.

Tom