Re: XAppleWMFrameDraw(), CoreGraphics, TWM
Re: XAppleWMFrameDraw(), CoreGraphics, TWM
- Subject: Re: XAppleWMFrameDraw(), CoreGraphics, TWM
- From: Jeremy Huddleston <email@hidden>
- Date: Sun, 28 Aug 2011 10:25:01 -0700
On Aug 27, 2011, at 14:06, Eeri Kask wrote:
> 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"?
Yes.
> 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?
Yes, the window currently receiving keyboard focus (assuming just one such window exists). This doesn't map well to future X11 work in general with multi-input, but that doesn't effect XQuartz directly since we have just one keyboard and mouse.
> 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"?
Yea, you need to decide that for your model.
>> 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.
Yeah, that code would make the decision of "front window" be the one with keyboard focus.
>> 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. :-)
Yeah, but AppleWM notifications don't correspond to given X11 windows. They are global.
>>> 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.
The line is very blurry at this point due to the nature of running one windowing environment within another.
>>> 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?
AppleWMReloadPreferences causes it to re-read preferences from disk.
AppleWMIsActive tells the WM that X11.app is now the active application.
AppleWMIsInactive tells the WM that X11.app is no longer the active application.
The latter two are mainly for controlling decorations.
_______________________________________________
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>) |
| >Re: XAppleWMFrameDraw(), CoreGraphics, TWM (From: Eeri Kask <email@hidden>) |