Re: XAppleWMFrameDraw(), CoreGraphics, TWM
Re: XAppleWMFrameDraw(), CoreGraphics, TWM
- Subject: Re: XAppleWMFrameDraw(), CoreGraphics, TWM
- From: Eeri Kask <email@hidden>
- Date: Sat, 13 Aug 2011 19:30:22 +0200
Huge thanks for the hints! :-)
On 08/08/2011 08:37 PM, Jeremy Huddleston wrote:
> The libXplugin API is not a stable API (check out the comment at the top of Xplugin.h). I've tried to ensure that it is binary compatible as I've been refining it, and I've tried to make it as easy as possible to support multiple versions of the API as it has been refined. Please use the newer applewmproto and newer Xplugin.h. I'd advise editing configure.ac to require the latest versions of libAppleWM and applewmproto. If you want to support building with older libXplugin (recomended), you can add this block to do the translation for you:
One of the comments in Xplugin.h says
"Note that these interfaces are provided solely for the use of
the X11 server. Any other uses are unsupported and strongly
discouraged."
which did lead to not consider using it for non-server works...
> #include <Xplugin.h>
> #if !defined(XPLUGIN_VERSION) || XPLUGIN_VERSION < 4
> #warning "Old libXplugin version detected. Some features may not be supported."
>
> typedef enum xp_frame_class_enum xp_frame_class;
> typedef enum xp_frame_attr_enum xp_frame_attr;
>
> #define XP_FRAME_CLASS_DECOR_LARGE XP_FRAME_CLASS_DOCUMENT
> #define XP_FRAME_CLASS_DECOR_SMALL XP_FRAME_CLASS_UTILITY
> #define XP_FRAME_CLASS_DECOR_NONE XP_FRAME_CLASS_SPLASH
> #define XP_FRAME_CLASS_BEHAVIOR_MANAGED (1 << 15)
> #define XP_FRAME_CLASS_BEHAVIOR_TRANSIENT (1 << 16)
> #define XP_FRAME_CLASS_BEHAVIOR_STATIONARY (1 << 17)
>
> #define XP_FRAME_ATTR_ACTIVE XP_FRAME_ACTIVE
> #define XP_FRAME_ATTR_URGENT XP_FRAME_URGENT
> #define XP_FRAME_ATTR_TITLE XP_FRAME_TITLE
> #define XP_FRAME_ATTR_PRELIGHT XP_FRAME_PRELIGHT
> #define XP_FRAME_ATTR_SHADED XP_FRAME_SHADED
> #define XP_FRAME_ATTR_CLOSE_BOX XP_FRAME_CLOSE_BOX
> #define XP_FRAME_ATTR_COLLAPSE XP_FRAME_COLLAPSE
> #define XP_FRAME_ATTR_ZOOM XP_FRAME_ZOOM
> #define XP_FRAME_ATTR_CLOSE_BOX_CLICKED XP_FRAME_CLOSE_BOX_CLICKED
> #define XP_FRAME_ATTR_COLLAPSE_BOX_CLICKED XP_FRAME_COLLAPSE_BOX_CLICKED
> #define XP_FRAME_ATTR_ZOOM_BOX_CLICKED XP_FRAME_ZOOM_BOX_CLICKED
> #define XP_FRAME_ATTR_GROW_BOX XP_FRAME_GROW_BOX
>
> #define XP_FRAME_ATTRS_ANY_BUTTON XP_FRAME_ANY_BUTTON
> #define XP_FRAME_ATTRS_ANY_CLICKED XP_FRAME_ANY_CLICKED
> #define XP_FRAME_ATTRS_POINTER XP_FRAME_POINTER_ATTRS
> #endif
Oh, its probably more code that needed.
Assuming the AppleWM protocol will remain "backwards binary
compatible", currently only that much is needed as minimum for the
title-bar painting (to denote focus-highlight, and
unfocus/nonhighlight) while calling XAppleWMFrameDraw() respectively:
#define APPLEWM_FRAMETYPE (1 << 0) /* AppleWMFrameClassDocument */
#define APPLEWM_FRAMEHILIGHT (0x0001 | 0x0004 | 0x0700)
/* AppleWMFrameActive | AppleWMFrameTitle | AppleWMFrameAnyBox */
#define APPLEWM_FRAMELOLIGHT (0x0004) /* AppleWMFrameTitle */
>> (2) What good purpose does the 'XAppleWMNotifyEvent'
>> (AppleWMControllerNotify, AppleWMActivationNotify, etc) offer?
>> How to use the XAppleWMSelectInput() function? Is it supposed to
>> work like XSelectInput()? Are these notify-events meant to be
>> utilised by a WM at all?
>
> Yes. It serves to pass along notifications from non-X11 sources for close, minimize, zoom, hide, and various other notifications that quartz-wm wants to know about. My advise to you at this point is to take a look in the server for what sends out those notifications and that'll hopefully help you understand them better.
>
> Chances are you won't need all of them, and if you find you need one that isn't there, we can always add it to the protocol.
I took a look at them. According to the first findings, it looks
like the 'window' field of 'XAppleWMNotifyEvent' is set to 'None'?
Because of this, that ControllerNotify stuff is unfortunately not
very easy to plant into twm in particular, as it skips events which
lack a reference to some window, be it even a root window of the
screen. In some cases like key mapping changes etc this window
field in the event structure is indeed irrelevant and dropping those
events by a WM altogether is probably justified too.
In respect to AppleWM it seems though in some cases, e.g. for
matters like 'AppleWMHideAll' and 'AppleWMShowAll' it would probably
make sense to fill this field with the value of the root-window-ID,
or something?
Further, if e.g. 'AppleWMMinimizeWindow' event comes along, the WM
is expected to know which client window is asked to minimize? (A WM
often has a client which gets keyboard input, so the easiest would
be to apply the operation to that client --- this would affect
Minimize, Zoom, Close, Hide, Next, Previous, and maybe few others.)
Then, it looks like every X11-client is allowed to independently
fiddle with the MenuItem list, and more surprisingly, execute
XAppleWMSetWindowLevel()
without WM's approval?
Keeping investigating,
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