Hi On Mon, 6 Nov 2006 12:16:49 +0000, "Richard Frith-Macdonald" <[EMAIL PROTECTED]> said: > Neither ... it should set it's level to be 50 and then place A > immediately above B
That's interesting, I thought the only way a window could change window levels was by the setwindowlevel: message. > > In the AppKit, there are two notifications, > > NSApplicationDidBecomeActiveNotification and its counterpart > > NSApplicationWillBecomeActiveNotification. Are these supposed to be > > sent > > through an application when one of it's windows is made "active" (i.e. > > becomes key)? Or is it when an application begins responding to event > > messages? > > They should be set when the app becomes active/inactive ... ie at the > point when it displays/hides its menus and panels. > So, if an app is inactive, and you click on any of its windows making > that window key, you will also be making the app active and the > notification would be sent, but if the app is already active and you > click on a different window, changing it to be key, then the > notification is not sent. I note there appears to be no private AppKit events defined in NSEvent.h for these nor could I find any instance in gnustep-gui when these are actually sent. Are they currently being used? I would imagine that they would be used by an application when a user cycles between apps running on a system e.g. I was using the Mac's at uni the other day, and I opened up Terminal with a main window (a terminal) and a font panel. When I switched to another application, the font panel disappeared. When I switched back, the font panel reappeared. I'll have to check the behaviour of some of these apps on Linux. 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? > > Win32 provides some window messages such as WM_ACTIVATE (a window > > in an > > application was given/lost the keyboard focus), WM_ACTIVATEAPP (your > > application itself lost/gained the keyboard focus) and > > WM_WINDOWPOSCHANGING/WM_WINDOWPOSCHANGED (called for a litany of > > window > > resize/move/focus/Z-order events where the outcome can be > > "adjusted"). I > > think these could help. > > <snip> > 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. 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? Cheers Chris -- Christopher Armstrong carmstrong ^^AT^ fastmail dOT com /Dot/ au _______________________________________________ Discuss-gnustep mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnustep
