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
_______________________________________________
Discuss-gnustep mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnustep
