Re: [AD] multiple windows

[Peter Wang <tjaden@xxxxxxxxxx>]

On 2006-08-16, Elias Pschernig <elias@xxxxxxxxxx> wrote:
> On Thu, 2006-08-17 at 00:46 +1000, Peter Wang wrote:
> > 
> > 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.
> > 
> 
> Can you give a more practical example? With the three windows and three
> tables, it might sense to only track the tablets in the drawing tablet,
  ^ tablets?
> and receive separate inputs from the tool selection and color selection
> windows. So in my use case, it would be practical to separate them :)

Note that we do have multiple joystick event sources.  This might be
closer to your multiple tablets example.  But we don't have a separate
joystick event source per window -- there is one AL_JOYSTICK per
physical joystick.

In your example it's not necessary that you have separate keyboard event
sources per window, but you would like the keyboard event source only to
deliver to certain event queues when particular windows are focused.  We
could add that to the API, or change/extend the behaviour of
al_wait_for_specific_event().

> > 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.
> 
> Is this possible in Windows, OSX or X11? I know it would work in DOS,
> but in those three you need either a window or fullscreen display I
> guess - which means, you wouldn't be able to track input without first
> creating an AL_DISPLAY anyway (even if only due to OS limitation
> then..).

Well, there are these key logging programs on Windows for example.

> > 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.
> > 
> 
> I see. With the global key event source, each window would in its
> (platform specific) event loop attach key events to the global keyboard
> queue.

What is a "global keyboard queue"?

On X, we have a background loop that gets X events from the X server.
If the incoming event is a keyboard event we convert that into an
AL_KEYBOARD_EVENT and say that it came from the keyboard event source,
and inject it into all the event queues which are interested in the
keyboard.  The keyboard event source is just a fiction -- event sources
only exist so that there is a uniform way to connect various event
generating things to event queues.

Other ports are basically the same, except they may have different
background threads or multiple background threads, etc.  On all ports we
use a separate timer thread to inject events.

> So yes, it shouldn't make a big difference. My view of an AL_DISPLAY
> currently is that of an OS window. And I believe we also will have an
> easier time when we can write in the documentation "al_create_display
> basically created a window" - compared to "al_create_display creates a
> target for graphics operations, which is independent of any input
> devices".

Keeping them independent might be conceptually simpler.

> > > 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.
> 
> Ok, I also believe it's the simpler design. But my idea was, we could do
> without threads if al_get_event() would call a driver method to query
> for OS events. It would work on the three platforms in any case. SO,
> well, maybe worth considering for a moment, right now it should not be
> hard to change it 

I think it will be hard.  If you have multiple threads waiting on
multiple Allegro event queues, it could turn really ugly as to who gets
to call XNextEvent(), and then having to deliver events to *other* event
queues.  Another problem is with events which are not related to X, e.g.
timer events.  Now you'd need to merge the events coming from X with the
events coming from timers together, which implies keeping a list of pending
timer events.

> - and some people think threads are evil.

Yet I still keep coming back to them :-)

> > > 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.
> > 
> 
> Did it work in your old A5 prototype? How did you implement that? As I
> see the X11 API, I need a focused window to get keyboard/mouse input.

I don't think I implemented it in the X port, but I did it in the Linux
console port (obviously).  AFAIK there are X11 programs which intercept
keyboard events without a visible window (e.g. to handle "Multimedia"
keys), but I don't know if they open an invisible window to do it.

Peter