Re: RFC: frame size hints

[Rob Adams <readams readams net>]

How does KDE do placement/implement struts/etc if it has no way to find
out how big the window frame is?

-Rob

On Thu, 2003-12-04 at 12: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:
> > > 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
> 
> 
> _______________________________________________
> wm-spec-list mailing list
> wm-spec-list gnome org
> http://mail.gnome.org/mailman/listinfo/wm-spec-list