On Sep 12, 2009, at 16:03 , Eeri Kask wrote:
Unfortunately I still don't grasp the idea... :-) I was in opinion these inner_? (and outer-?) parameters denote some rectangular area, with coordinates relative to the corresponding X11-window origin on the screen; therefore an area sized (w+2b, h+2b) at offset (-b,-b) exactly encloses the X11-window area including its border. But apparently this opinion is wrong.
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.
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. (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.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH