[Xquartz-dev] X11 window appearance

[Eeri Kask]

Am 09/01/2009 06:21 PM, Jeremy Huddleston schrieb:
>> Here is what I meant by the shadow-creator 'daemon':  catch
>> MapNotify, UnmapNotify, and maybe ConfigureNotify events for all
>> top-level X11-clients,
> 
> That's what a WM is.
> 
>> and then ask CoreGraphics to put or remove
>> shadow around these.
> 
> yeah, that's part of the window frame drawing code in libXplugin.
> 
>> --- Initially I meant to suggest to extract
>> exactly this part from quartz-wm into a separate program, for
>> everybody's use, regardless if some window manager is running or
>> not.  :-)


Let me present the effort of recent few spare evenings on that topic
and ask for some further help while finalising/polishing.  :-)


I have created a really small program to be started from .xinitrc
into the background and which has to do more or less only this.

(1) Catch the abovementioned X11 events and put the usual Aqua-like
shadow around X11-windows.

(2) This program has not to rely on something else like some other
window manager be in use, i.e. it has to run on plain X11-server as
well as while some common window manager is in use like
/usr/X11/bin/twm or whatever.

(3) Therefore this program has to take the X11-window as it is
regarding any existing decorations: it has not to rely on anything
at top-level in that respect; e.g. the title bar, if any, has to be
provided by some entity as part of the top-level window.


First I studied the Xplugin to use but quickly found out, there
exists the "Apple-WM" X11-extension which could probably be utilised
by that small program; and it appears mostly it is only the

    XAppleWMFrameDraw()

function which does most of the work.


In the following may I explain what this program does in particular.

First, while starting it does not scan for all top-level windows and
 put shadow around these.  This is intentional, as so one can
exclude some clients from being shadowed by putting these in front
of this client into .xinitrc.

Second, we attempt to track focus (a la "active-window") and utilise
the "AppleWMFrameActive" parameter to XAppleWMFrameDraw() to
emphasize the client which has focus.  Though, if the server is in
PointerRoot mode we cannot catch FocusChange events, so the simplest
alternative in this case is to track Enter/Leave events and
emphasize the client with the mouse inside.
Then, there is the "-a" command-line parameter which turns off this
"active-window" chasing altogether, which means all clients get the
"inactive" shadowing which isn't changed later.


There are few aspects concerning the abovementioned
XAppleWMFrameDraw() function though, which I have't quite understood
yet due to very sparse documentation:


(1) What are these inner_x, inner_y, inner_w, inner_h parameters in
particular?  I observed the CoreGraphics is pretty robust in that
respect, e.g. if setting all to zero, in most cases (i.e. usual
rectangular windows) nothing unusual can be observed regarding the
shadow the CoreGraphics subsystem draws. Exeptions are xeyes and
oclock, while having a shaped top-level window, they get undefined
shadows if the abovementioned call parameters do not exactly match

    0, 0, w, h

where w and h are the window width/height without counting the area
of the border (border in the sense of the X11-window 'attribute').
Though, it seems the CoreGraphics draws the shadow by taking that
border area into account!   (I expected these above arguments to be
-1, -1, w+2b, h+2b where 'b' is the border_width; but this screwed
the CoreGraphics the same way if called with all zeros for xeyes and
oclock.)


(2) Not knowing any better I chose 'AppleWMFrameClassBorderless' as
this seemed  most appropriate to denote the CoreGraphics not to put
any of the usual Aqua title-bars, drag-knobs, its own border, etc
around the final result.  In fact, what does this 'class' parameter
like 'AppleWMFrameClassDocument' denote, regarding the shadow
drawing, if it affects anything at all?


(3) The second, the 'attribute' parameter seems clear:  it looks
like only 'AppleWMFrameActive' and '0' make sense here... ?


(4) Most important unresolved issue is termination: how to withdraw
the shadows by means of Apple-WM extension?  In particular, if
quartz-wm is started manually, and terminated by Ctrl-C, then it
withdraws all shadows.  How does it do that?   :-)
In fact I would put this code to be executed on 'UnmapNotify' events.


Greetings, and huge thanks in advance for any comments and
clarifications,


    Eeri Kask


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: AppleWM_xshadow.c
URL: <http://lists.macosforge.org/pipermail/xquartz-dev/attachments/20090912/fa0eec33/attachment.c>