Re: [AD] Some thoughts about multi-window applications

[Evert Glebbeek <eglebbk@xxxxxxxxxx>]

On 12 Aug 2009, at 10:15 , Elias Pschernig wrote:
> > 2. Related question: I'm working under the assumption that the last
> > created window has input focus. Is this true on all platforms (it
> > would make sense)?
>
> Definitely not - for example compiz has 5 different "focus stealing
> prevention" options and most of them will not allow new windows to get
> focus (or be raised above the window which currently has focus).

Well, that's bad.
Let me clarify though: if the application that has input focus opens a  
new window, it would make sense to me if that new window received  
input focus. The rationale being that the window is opened in response  
to a user action and the user needs to interact with the window next.
Conversely, a background process should never raise a new window that  
gets input focus. That's not how it works?

Either way, if the behavior I described cannot be relied on across  
platforms, then that's bad from the point of view of writing platform  
independent code. In my opinion, it is not enough to document that the  
key window is undefined after a new display has been opened, but it's  
not clear to me what to do about it, given the different focus  
policies on different systems.
Clearly Allegro is no supposed to be a cross-platform window  
management library, so we shouldn't go overboard here. But we do need  
some way to make behavior consistent (or as consistent as possible)  
across platforms.

Maybe the easiest would be either one of the following: if there is no  
Allegro window currently open, the next window created tries to become  
the key window. Subsequent windows do not attempt to be come key  
windows at all, so all things being equal, the first Allegro window to  
be opened gets focus and keeps it, unless the user switches to another  
window. Or every new Allegro window that is opened tries to become the  
key window, so that the last window to be opened gets keyboard focus.  
That is the current situation on OS X.

Alternatively, could we add functions to query which (Allegro) window  
currently receives keyboard input (this might be NULL if no Allegro  
window has input focus) and to tell an Allegro window to try to get  
keyboard input? Eg,
ALLEGRO_DISPLAY *al_get_key_window(void);
void al_make_key_window(ALLEGRO_DISPLAY *dpy);

From memory (I think this has come up before), the following is true  
on different platforms:

X11:
Top window (no other windows are above this window)
Key window (this window receives keyboard input)
Mouse window (this window recieves mouse input)
The relation between these windows can be different, depending on the  
focus policy (in particular focus-follows-mouse versus focus-under- 
mouse)

OS X:
Key window = Top window
Mouse window

Windows:
Key window = Mouse window = Top window

An alternative to my suggestion above then would be to query which  
Allegro Window is the top window and to ask an Allegro window to raise  
itself to the top. On Windows and OS X these would do the same thing  
as my suggestion, on X11 it might be different.

Or we could provide both, which might be a reasonable alternative if  
we can't agree on a single set of functions.

Hmm... long post.

> X11 provides it I think - from what I remember it's even needed  
> already
> for the implementation of al_toggle_window_frame as that would move  
> the
> window by just that amount otherwise.

Ok, OS X provides it as well (and we may even use this as well, I  
didn't check the code), so that should be easy to add. Is there any  
expected difficulty in Windows? I vaguely recall there being some sort  
of issue with themed/customised window decorations and reported window  
sizes, at least in XP?

Evert