Re: XAppleWMFrameDraw(), CoreGraphics, TWM
Re: XAppleWMFrameDraw(), CoreGraphics, TWM
- Subject: Re: XAppleWMFrameDraw(), CoreGraphics, TWM
- From: Eeri Kask <email@hidden>
- Date: Sat, 27 Aug 2011 23:06:19 +0200
On 08/22/2011 04:56 AM, Jeremy Huddleston wrote:
>> In particular, the above event comes from (or through) the
>> X11-server (it doesn't matter if it originates from OSX or not),
>> contains a 'window' field, asks some window e.g. to be 'closed', and
>> then the 'None' window is specified.
>
> No, you're missing the point. The server is not asking a known window to be closed. It's asking for the "front" window to be closed, and the WM is responsible for knowing this.
To verify: by "server" you mean "X11-server"?
Having checked, neither ICCCM nor EWMH specifications talk about a
concept of a "front window", so it may be something related to
policies and preferences implemented by some particular GUI-desktop
environments?
In twm's design there is no place where such "front window" concept
comes in; it passes the flexibility of X11-technology unaltered to
the user instead: consider a realistic situation, we have three
windows layered as follows:
+-------------------------------+
| gets X-keypress events |
| due to 'f.focus' |
| |
+-----------------------------+ |
| gets X-buttonpress events | |
| by moving mouse here | |
| | |
+-------------------+ | |
| | | |
| is top-of-stack | | |
| due to 'f.raise' | |-----+
| |-------------+
| |
+-------------------+
which of these windows would you consider a "front window"?
>> Lets recapitulate, while running as part of the X11-server the
>> AppleWM extension has direct access to the "ground truth" about
>> which client is assigned keyboard input (either because 'focused' or
>> contains the pointer if running in PointerRoot) at *any* moment of
>> time
>
> Ok, try changing it from None to darwinKeyboard->deviceGrab.activeGrab.window->drawable.id (I think that is correct). If that works for you, send me a patch, and I'll include it. Unfortunately that still means that your changes will only work on servers that have that change.
I assume you reference some X-server code segment where I am
unfortunately unfamiliar, but one day I'll probably take a look at it.
> You'll still need to react intelligently to window == None.
Looking at the above picture and therefore not knowing any better,
the most obvious reaction would be to close a window with ID 'None'
as specified by the X-event, much the same we always respect
window-IDs in X-events in all situations without exceptions. :-)
>> Then, to return to twm, if the above events are in practice meant to
>> respond to user-initiated functions on X11-clients, then most of
>> this stuff is 'repeated functionality' anyways as it is easy to
>> instruct twm e.g. to close a window by cmd-w by the means of .twmrc
>> (if the user so wishes).
>
> Right, but there's no way to configure twm to react to events from OSX directly. That is what these mechanisms are for. They let you react to sources that may not even exist yet or global OSX preferences (perhaps they have a fancy keyboard with a "close window" button or map "close window" to button 20 on their megamouse. It's designed to pass along a notification that originates from outside of X11, not to pass along a cmd-w keypress.
It is controversial if an X11-WM should react to events of a
particular OS at all. In particular, twm is X-window manager by
design and has to react to X-events instead. OSX or any other OS on
the other hand could map its requests and duties through X-server
onto 'non-conflicting' X-event sequences and there is no problem for
twm or any other WM to operate appropriately.
>> Finally, a different story seems to be 'Hide' and 'Show' as they
>> seem to be part of something like ... user interface guidelines of
>> the 'Aqua-Desktop-Enviroment'. In this case it makes sense the
>> X11-server (or AppleWM-extension) to ensure all windows are taken
>> off screen and put back, not? Because it seems logical that it
>> makes sense to respect these guidelines even if there is no WM
>> running at all, doesn't it?
>
> Yeah, but WMs other than quartz-wm aren't well supported configurations.
While being at it, what is the aim of 'AppleWMActivationNotify'
events? What purposeful does quartz-wm do in response to these?
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
References: | |
| >XAppleWMFrameDraw(), CoreGraphics, TWM (From: Eeri Kask <email@hidden>) |
| >Re: XAppleWMFrameDraw(), CoreGraphics, TWM (From: Jeremy Huddleston <email@hidden>) |
| >Re: XAppleWMFrameDraw(), CoreGraphics, TWM (From: Eeri Kask <email@hidden>) |
| >Re: XAppleWMFrameDraw(), CoreGraphics, TWM (From: Jeremy Huddleston <email@hidden>) |
| >Re: XAppleWMFrameDraw(), CoreGraphics, TWM (From: Eeri Kask <email@hidden>) |
| >Re: XAppleWMFrameDraw(), CoreGraphics, TWM (From: Jeremy Huddleston <email@hidden>) |
| >Re: XAppleWMFrameDraw(), CoreGraphics, TWM (From: Eeri Kask <email@hidden>) |
| >Re: XAppleWMFrameDraw(), CoreGraphics, TWM (From: Jeremy Huddleston <email@hidden>) |