Re: Backend <-> GUI Library Interaction

[Christopher Armstrong]

Hi

Richard Frith-Macdonald wrote:
> > That's interesting, I thought the only way a window could change window
> > levels was by the setwindowlevel: message.
>
> I thought the same until I checked.  The documentation suggested that 
> behavior but was not completely explicit, so I looked at the X backend 
> code to confirm it.
> The other interpretation (that ordering of windows relative to each 
> other only worked for windows in the same level) seems a bit more 
> intuitive to me.
>
> It actually might be worth checking what MacOS-X actually does, and 
> consider changing the GNUstep behavior if it does it the other way.
There seems to be a little debate about this one (re: message from 
Sheldon Gill). I'll have to dig a bit deeper on this, but I think the 
MacOSX notes are ambigious too (IIRC).

> There is GSAppKitWindowFocusIn to tell the gui when a window is given 
> focus.  This is really a hack to cope with X ... since what the gui 
> really wants to see is a mouse click in the window.
> The notifications are sent by NSApplication ... the backend doesn't 
> need to do that ... it could call the NSApplication 
> activateignoringOtherApps: method to activate the app, but activation 
> is probably done implicitly (ie the backend tells the gui that a 
> window has been given focus, and the gui noticing that it is inactive 
> but has just had a window become key, changes to become active.
> When focus leaves a window without being given to another window of 
> the app first, the backend tells the application to deactivate itsself.
I'm not sure that the backend for Windows is telling the GUI all of this 
information. Actually a check reveals that the "key" status is being 
handled directly by the backend to avoid "recursion" problems (some sort 
of race condition I expect) in response to the WM_SETFOCUS method. 
WM_ACTIVATE and WM_ACTIVATEAPP are just stubs. Perhaps this needs to be 
investigated further.

> > Should I add some events to gnustep-gui which notify the frontend of
> > these changes, or should I just post the notifications myself from the
> > backend?
>
> You don't need to do anything ... the NSApplication will post the 
> notifications.
>
> > > It sounds like WM_ACTIVATEAPP should trigger app activation and
> > > WM_ACTIVATE should tell the app to change the key window and the
> > > others should do window movement ... I would have thought that the
> > > win32 backend was already using these in some way ... I guess not
> > > optimally though.
> > Actually, not really at all. They are stubbed out though for "future
> > implementations". Only some more basic events appear to be handled.
>
> Perhaps they are not needed because other events provide the same 
> information implicitly?
> For instance, WM_ACTIVATEAPP would be equivalent to a focus in event 
> for the key wndow,
> However, I would have thought that WM_ACTIVATE was necessary ... 
> unless windows always sends a mouse click event when focus goes to a 
> window.  If it always sends a mouse click then nothing else should be 
> necessary as the receipt of the mouse click should let the gui make 
> the window key.
I guess the user can "Alt-Tab" to a window, amongst other means. Windows 
is pretty flexible with these things.
> > There was another case I also forgot to mention. I believe NSPanel can
> > be inherited and its windows prevented from becoming "key" and becoming
> > "main". How does gnustep-gui expect the backend to handle this? I'm
> > presuming it just resets the keyboard input focus if a window tries to
> > become key, or does it expect the backend to prevent this situation?
>
> IIRC is done in the gui at present ... if focus is given to something 
> which shouldn't have it, the gui resets focus to the key window.
> I guess the backend could do the same thing without ever bothering the 
> gui layer ... but that would require some duplication of code to check 
> whether the window given focus can accept it, so it's probably best 
> left to the gui to handle it.
Okay I think this means that the backend just needs to make sure that 
the frontend knows when one of its windows receives the focus.

Cheers
Chris