Thanks Jeremy, Brandon, for the explanations, this did resolve the situation a bit.
By convention a window is represented in terms of internal height and width, excluding the border; you do not use (-bw,-bw) to represent a window offset, but (0,0). The border width comes into play only when representing the window's position relative to its parent.
Yes indeed, but only if considered in the X11-windows coordinate system convention. The CoreGraphics-one is apparently a little different. I am afraid I discovered a little tohuwabohu in this regard in Xplugin or whereever. In particular, in applewm.h one finds Bool XAppleWMFrameDraw (Display *dpy, int screen, Window window, unsigned int frame_class, unsigned int frame_attr, short inner_x, short inner_y, short inner_w, short inner_h, short outer_x, short outer_y, short outer_w, short outer_h, unsigned int title_length, const unsigned char * title_bytes); For our purposes, in points where it matters it seems it should read something like Bool XAppleWMFrameDraw (Display *dpy, int screen, Window window, unsigned int frame_class, unsigned int frame_attr, short inner_x, short inner_top_edge_measured_from_outer_top, short inner_w, short inner_h, short outer_x, short outer_y, short outer_w, short outer_top_edge_measured_from_canvas_bottom, unsigned int title_length, const unsigned char * title_bytes); It looks like the CoreGraphics subsystem treats the X11-window area (inclusively the border area!) as its drawing canvas in cartesian coordinate system, i.e. origin at bottom-left, and not in a text-editor coordinate system with origin at top-left. So, shifting "outer_top_edge_measured_from_bottom" one can move the title-bar arbitrarily vertically across the canvas, and by setting it to zero, the title-bar will run along the window bottom edge. The Xplugin (or whatever) seemingly does not look at "outer_y" at all, so nothing goes wrong in setting it beyond the canvas altogether. Completely different story is "outer_x", "outer_w", these denote a distance from the left canvas edge, and the "width" is "width", so only changing "outer_x" shifts the title-bar arbitrarily horizontally across the canvas, the rendered width of this title-bar remains the same. Then, it looks like we have the "inner" area in text-editor coordinates again, i.e. the "inner_y" is to be measured relatively to the "outer" rectangle top edge. This is intuitive, isn't it? :-) To recapitulate, the outer rectangle should have these coordinates in order to cover the X11-window plus border area: 0, 0, w+2b, h+2b-1 where "w+2b" is mathematical "length" as opposed to "h+2b-1" which is mathematical "distance", in integer coordinates. This all above works perfect for "usual" rectangular X11-windows and one has to ensure the "inner_y" parameter is zero, otherwise some part of the Aqua title-bar will appear. Though, for xeyes, oclock and probably other heavily X11-shaped top-level windows one has to set all "inner"-parameters to zero in this configuration in order to have them shadowed too by CoreGraphics.
The applewm.h file lists these frame classes:
AppleWMFrameClassDocument AppleWMFrameClassDialog AppleWMFrameClassModalDialog AppleWMFrameClassSystemModalDialog AppleWMFrameClassUtility AppleWMFrameClassToolbar AppleWMFrameClassMenu AppleWMFrameClassSplash AppleWMFrameClassBorderless
and I originally took the last one. It appears each and everyone of these looks the same-shadowed after being rendered, I did try all of
I would expect these to differ in ways other than drop shadows, i.e. a dialog may not have a maximize button and is often centered in its parent window, while menus are usually placed at the pointer location.
Yes I could confirm this. They differ in top-left buttons sizes and title-text height. Then, interestingly "AppleWMFrameClassBorderless" returns zero for title-bar height if checked by XAppleWMFrameGetRect(), but somebody does render the title-area including the three buttons plus title-text nevertheless!
(So why does PaintShadow() support them? So you can use the same window type everywhere instead of having to use a different specifier for each API function.)
Oh, PaintShadow() doesn't support them; it uses only "AppleWMFrameActive" if the client is focused, and zero otherwise for "inactive". Greetings, Eeri Kask