Backend <-> GUI Library Interaction

[Christopher Armstrong]

Hi

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. 

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. 

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

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? 

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.

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?

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

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.

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.

Cheers
Chris
-- 
  Christopher Armstrong
  address@hidden