Re: Backend <-> GUI Library Interaction

[Sheldon Gill]

Hi Christopher,

Nice to hear from you...

Christopher Armstrong wrote:
> There are outstanding issues with the windows backend related to window
> management. I believe some of these can be fixed by responding to
> certain Win32 window messages that MSWindows posts out. I am referring
> to the problems with window layering/levels/ordering and related focus
> issues that seem to affect everything from windows going missing to
> modal windows playing up. 

Not to mention the click twice to edit problem ;)

> There are some methods which appear in GSDisplayServer that appear to
> relate to these things. Without checking in detail what gnustep-gui
> does, could I get some clarifications on how the following methods work
> in response to certain inputs/outputs.
>
> - (void) orderwindow: (int) op : (int) otherWin : (int) winNum
>
> This one does appears to do window ordering (to state the bleedingly
> obvious). Obviously when a window is ordered it should obey the window
> level that is set. 

It should order self relative to otherWin according to op (NSWindowAbove, 
NSWindowBelow etc), staying within it's level.

> Take a hypothetical situation with three windows:
>
> A - window level 0
> B - window level 50
> C - window level 0
>
> C is above A. B is on top of A & C (in terms of Z-order).

So we have B-C-A (z-order front to back)

> if orderwindow was called to place A on top of B, should it order A to
> the top of its window level (i.e. between C and B) or should it ignore
> the message? 

I'm not sure what Cocoa does and it would be best to behave compatibly.
That said, I think it should reposition itself to the top of its level so we'd 
get B-A-C

> Say the reverse happened (orderwindow was called asking it to order a a
> lower level window above a higher level window), what should occur in
> that case? The backend currently does what gnustep-gui tells it to do,
> ignoring window layering.

That is wrong. Layering should be respected at all times.

> 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?

?? we have NSApplicationDidBecomeKeyNotification and 
NSApplicationDidBecomeMainNotification
Do don't have NSApplicationDidBecomeActiveNotification

> - (void) setinputfocus: (int) winNum
>
> In GNUstep parlance there appear to be two things: a key window (which
> responds to keyboard events) and a main window. Is this correct? How
> exactly does a main window fit into the window focus equation? Is
> setinputfocus: supposed to main a window "key"? If a window is not to
> become the key window (e.g. some floating palette windows), does
> gnustep-gui take messages from the backend that the window was made the
> key window, and respond by making another window the key window?

setinputfocus: sets focus to the window so it will receive key events. This is 
the X11 idea of focus, by the way. So on windows it makes the window active.

The main window has a responder chain to processes the menu etc. So if you have 
a floating palette it can become 'key' but will never be 'main'.

> 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.

Probably, although correcting calls to SetWindowPos() should fix the vast 
majority of problems.

> Does anyone have some guidance on this matter? I would like to start
> investigating some fixes so that perhaps I could get this working on
> Windows properly.

Great.


Regards,
Sheldon