Re: XAppleWMFrameDraw(), CoreGraphics, TWM
Re: XAppleWMFrameDraw(), CoreGraphics, TWM
- Subject: Re: XAppleWMFrameDraw(), CoreGraphics, TWM
- From: Jeremy Huddleston <email@hidden>
- Date: Sat, 13 Aug 2011 12:31:54 -0700
On Aug 13, 2011, at 10:30 AM, Eeri Kask wrote:
> 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...
Yeah, that comment should probably say "X11 server, GLX, and AppleWM" ...
> Oh, its probably more code that needed.
>
> Assuming the AppleWM protocol will remain "backwards binary
> compatible",
Yes, it will remain backwards compatible. If it ever *doesn't*, then it will get a major version bump and the old one will be kept around for binary compatibility (like we did for Xaw and png).
> 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 */
Don't do that. I'm trying to eliminate duplicated code. Use the constants provided by Xplugin.h instead.
Use XP_FRAME_CLASS_DECOR_LARGE instead of APPLEWM_FRAMETYPE
Use XP_FRAME_ATTR_TITLE instead of APPLEWM_FRAMELOLIGHT
Use (XP_FRAME_ATTR_ACTIVE | XP_FRAME_ATTR_TITLE | XP_FRAME_ATTRS_ANY_BUTTON) for your "APPLEWM_FRAMEHILIGHT" but try calling it something more consistent, like _XP_FRAME_ATTRS_ACTIVE_TITLE_ANY_BUTTON.
>>> (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'?
Yeah, that's what it looks like... these events usually correspond to events from outside X11 itself (usually from OS X) and correspond to the "front" window or the application as a whole.
> 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.
Well then you'll have to hack around that. You should have a handler for each notification type rather than trying to manage them all in one giant handler.
> 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?
Maybe it would've, but there are a ton (all) of servers out there that don't do this now, so that's not a great solution if you want to work on existing systems, and the fix is easy to do in your wm.
> Further, if e.g. 'AppleWMMinimizeWindow' event comes along, the WM
> is expected to know which client window is asked to minimize?
Yes, the active one.
> (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.)
Yep.
> 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?
Yep.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
X11-users mailing list (email@hidden)
This email sent to email@hidden