discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Backend <-> GUI Library Interaction


From: Christopher Armstrong
Subject: Re: Backend <-> GUI Library Interaction
Date: Tue, 07 Nov 2006 19:11:23 +1100
User-agent: Thunderbird 1.5.0.7 (Windows/20060909)

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]