[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Re: Java applets and ConfigureRequest
From:       Leon Bottou <leon () bottou ! org>
Date:       2003-12-07 2:25:59
[Download RAW message or body]

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. 

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.

- L


[prev in list] [next in list] [prev in thread] [next in thread]