Re: [AD] multiple windows

[Peter Wang <tjaden@xxxxxxxxxx>]

On 2006-08-16, Elias Pschernig <elias@xxxxxxxxxx> wrote:
> On Wed, 2006-08-16 at 23:18 +1000, Peter Wang wrote:
> > 
> > After the discussions on the alleg-bigfive list, the keyboard event
> > source was decided to be global.  Otherwise if you have N windows and M
> > input devices, you need to keep track of N*M event sources.  There is a
> > field in the AL_EVENT structure which tells you which window was in
> > focus at the time the event was generated.
> 
> Doesn't it make more sense to have them separate? I might want to have
> two different event handlers for my different windows (e.g. a game
> window and a console window). So I would have an event queue for the
> game window, and one for the console window.
> 
> My main program probably would do something like:
> 
> handle_game_window();
> handle_console_window();
> 
> If both get the events of both, and I need to filter them out by the
> event.window member, that seems to not make too much sense.
> 
> If I have N windows (in 99% N is 1) then I would expect to handle N*M
> event sources. But I don't remember the discussion you mention, what was
> the reason to merge them into one global queue?

There's not "one global queue", there's just one global keyboard source.
It happens to generate a event no matter which window is focused.

As I said, the reason for just having one keyboard source is practical.
It's a pain to keep track of all the different event sources.

Also, it can be that you are not using any Allegro displays at all.
You should be able to use the Allegro keyboard routines anyway.
And we might want to be able to track keyboard event even if *no*
Allegro windows are focused.

I found a bit of discussion in [1].  (Wow, has it really been so long :-( )
Your idea is actually slightly different, in that Allegro will track the
keyboard-event-source-of-this-window for you, so you could always call
al_get_keyboard(window) and forget about holding onto the pointers.
Maybe I could live with that but I'd have to think about it more.

> > > Does it all make sense? So basically, xwin.c in 4.2 is not executed by
> > > allegro_init(), but by each al_create_dispay().
> > 
> > Not sure what you mean by that. 
> 
> Well, we have two windows to handle, so each has to do its own
> XNextEvent. Do we still need a background thread in 4.3 btw?

Yes.

> > For example, at least the compatibility
> > layer should be able to 'install_keyboard' before 'set_gfx_mode', and
> > even in the new API it would be nice to do that.
> > 
> 
> Yes, the compatibility layer could create an initial dummy AL_DISPLAY in
> allegro_init.

As I mentioned just before, it might be nice to use the Allegro input
routines without an (Allegro) window open.

Peter


[1] http://sourceforge.net/mailarchive/forum.php?thread_id=1362004&forum_id=11854