[Xquartz-dev] X11 window appearance

[Eeri Kask]

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