Re: Backend <-> GUI Library Interaction

[Christopher Armstrong]

Hi

On Mon, 6 Nov 2006 12:16:49 +0000, "Richard Frith-Macdonald"
<richard@tiptree.demon.co.uk> 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