Re: [AD] multiple windows

[Elias Pschernig <elias@xxxxxxxxxx>]

On Thu, 2006-08-17 at 21:10 +1000, Peter Wang wrote:
> > 
> > Well, the global AL_KEYBOARD. Was just repeating to myself how it works
> > at the driver level - each one attaching to it.
> 
> That's just confusing to me, as AL_KEYBOARD is not a queue and does not
> behave as one at all.
> 

Hm, yes, I didn't look at the implementation, only at the user API.. but
I assume, keyboard drivers will attach to some queue at least, even if
it's not AL_KEYBOARD. Hm, we really should somewhere have design
documents for stuff like this.. but then there would even more time be
needed than for threads like this :)

> > 
> > Ah, well, I assume my upper ASCII pictures in the beginning are still
> > right though - basically, there is one X11-event handler for each
> > window, which filters out keyboard events, and then puts them into the
> > (platform independent) global AL_KEYBOARD. (And all the X11-handlers are
> > handled from the same background thread.. but we could even use a thread
> > for each if we want.)
> 
> No, there can only be one X11 handler for the program, unless you open
> multiple connections to the X11 server.  The way it works now is:
> 
>             X11-events          (incoming events)
>                 |
>              handler            (background thread)
>                 |
>             xkeyboard.c         (massage events, create AL_EVENTs)
>             /   |     \
>        queue   queue   queue    (these are AL_EVENT_QUEUEs)
>         |       |       |
>        user    user    user     (userspace)

I see, I had indeed used multiple X11 display connections (and also
thought there is a window parameter to XNextEvent). This means, the
system driver should call XOpenDisplay, and all the display drivers
should re-use the connection. So yes, that way your design is closer to
how X11 works.

> > 
> > Well, I do not see the usefulness of timer events, to be honest. But
> > it's just that I personally prefer al_get_time() and timeouts, which
> > feels more natural to me.
> 
> Not if you are writing an event driven program.  Ok, you could use
> timeouts but that's a last resort and hard to do right (you'd basically
> reimplement the timer background thread).
> 

Yes, just a timeout to wait for the difference to the next update. And
yes, that would work in a purely event driven model as well. Just many
other types of game loops don't map to an event driven model (like using
"delta times", or maxing out FPS, interpolating frames, skipping frames
or adjusting the global clock) - but mostly those look all inferior.

> > Even in the linux console port, it would be ok for users to create an
> > AL_DISPLAY first though. We should try to find the common denominator
> > here, not look at the possibilities of exotic ports. I consider it
> > exotic, since I don't think when 4.4 comes out many will play Allegro
> > games in linux console :)
> 
> Sure.  Windowless keyboard input was just an example.  Actually, we can
> keep the possibility if we allow al_get_keyboard(NULL).
> 
> 
> Anyway, if you want per-window keyboard event sources (and other people
> seem to agree) I guess it's okay since the problem with keeping track of
> N*M event sources is not really bad as in my old design.  It should not
> be too hard to add to the current implementation.  I think the
> implementation could be quite different from what you think, though.

Yes, I was assuming we already get all events separated for our windows,
so it would have seemed artificial to have no way to get them
per-AL_DISPLAY as in the current API (and instead only per-input-type).
In most cases, there will be one single place to handle all Allegro
events anyway, so then it won't matter at all.

In fact, the system I had in mind could maybe done by chaining an
additional events dispatcher to the end of the current events system.
Something like:

AL_EVENT_QUEUE main_window_events;
AL_EVENT_QUEUE console_window_events;

my_keyboard_dispatcher(global_keyboard_event_queue)
{
   event = al_get_next_event(global_keyboard_event_queue);
   if (event.display == main_display) al_add_event(main_window_events, event);
   if (event.display == console_display) al_add_event(console_window_events, event);
}

my_main_handler()
{
   event = al_get_next_event(main_window_events;);
   ...
}

my_console_handler()
{
   event = al_get_next_event(console_window_events;);
   ...
}

So even with many windows, my final per-window handlers would only
receive events intended for them. Of course, that would somehow require
an "al_add_event" function.. not sure how feasible that is.

> 
> Would we still have al_install_keyboard()?  It was nice that each event
> source type had an al_install_*() equivalent.
> 
> How do you want joystick and mouse input devices to behave?  I think
> joysticks should NOT be per-window.

Mouse button events should be the same as keyboard I'd say. Whatever the
OS/WM says is the window who retrieved the click should handle it. I.e.
if it would be two different applications, and one would get the click,
then two windows both managed by the same Allegro application should
have the click assigned to a window in the same way.

As for mouse movement events, I would also like to follow the OS. Here
(e.g. when I run xev) this seems to be: The window under the mouse
cursor gets the events. So I assume, if we simple map the window from
X11 events to the corresponding AL_DISPLAY somehow, this should work.

The "warp-to-middle" hack still seems to be needed :/ But we should add
a function to confine the mouse cursor to the window, so it cannot
accidently leave it, like in 4.2.0.

And I have no idea about joystick.. I'd have said it should always
affect the window with keyboard focus. But I never had a joystick, so
can't really say much how the OS/WM (if at all) handles it.

-- 
Elias Pschernig