Java applets and ConfigureRequest

[Lubos Lunak]

On Sunday 07 of December 2003 03:25, Leon Bottou wrote:
> On Saturday 06 December 2003 18:01, Koos Vriezen wrote:
> > Well, I found a way arround it (making the frame undecorated). However
> > it's strange a withdrawn window still thinks it has borders. For a well
> > embedded applet the Insets are 3,29,3,3 and the bouds are -3,-29,...
>
> There is a difference beween the borderwidth in X11 and the width of the
> window decoration. The borderwidth thing in XConfigureWindow is more
> fundamental.  Maybe a leftover of X10. Every X11 window can have a border
> drawn by the server.  If I remember correctly, the x and y specified in
> XConfigureWindow() position the topleft corner of the window border.
> Therefore the point (0,0) in the window coordinates overlaps the point
> (x+borderwidth,y+borderwidth) in the parent window.

 I strongly doubt this all has anything to do with X11 borders. And the WM is 
allowed to reset it to 0 anyway.

>
> If a toolkit captures the x,y,width,height and border_witdh during each
> ConfigureNotify event, then it is theoretically possible to reimplement
> XTranslateCoordinates() without round trip to the server. However when a
> toplevel window receives a ConfigureNotify event, it is very advisable to
> mistrust x and y. Here is why:
>
> Reparenting window managers often send synthetic configure events because
> moving a window is implemented by moving its parent window with all the
> decoration. The position of the application window relative to its parent
> does not change. No ConfigureNotify.  Therefore the window manager sends a
> synthetic event. But what should they put in x and y?
> There are two schools:
> -  Some provide the position relative to the window decoration.
>    This is not very useful, but this is consistent with what you get
>    when there is a real ConfigureNotify event (when resizing for instance).
> -  Some try to provide the position relative to the root window.
>    But this is not consistent with the real ConfigureNotify events.
>    It seems that the qxembed code tries to do this.
>
> I believe that qxembed sends fake ConfigureNotify events for the sake
> of some application that depends on the values of these x and y.
> In my book this application is wrong.  But I do not know which one
> this is and cannot correct it.  Maybe it is long gone.

 See ICCCM, section 4.1.5. Synthetic configure notify events are supposed be 
relative to root window, and QXEmbed does it right. Not that it actually 
matters, as QXEmbed blocks are configure requests  (I think it should honor 
size changes, and also handle min/max sizes).

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