Re: X11 window appearance
Re: X11 window appearance
- Subject: Re: X11 window appearance
- From: Eeri Kask <email@hidden>
- Date: Tue, 15 Sep 2009 19:38:26 +0200
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
_______________________________________________
Do not post admin requests to the list. They will be ignored.
X11-users mailing list (email@hidden)
This email sent to email@hidden