Re: [AD] multiple windows

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


On Thu, 2006-08-17 at 16:09 +1000, Peter Wang wrote:
> 
> 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().

Yes, it's really a question which design maps more to what the user
wants.

My scenario (which i see I formulated somewhat unintelligible before :P)
would be like this with a global keyboard source:

      X11-events       
xwin   xwin   xwin
  |       |      |
AL_DP1   AL_DP2  AL_DP3
  |       |      |
drivers put them into global keyboard queue
 /|\     /|\    /|\
user     user    user
  |       |      |    

And like this with separate keyboard sources:

    X11-events      
xwin   xwin   xwin
  |       |      |
AL_DP1   AL_DP2  AL_DP3
  |       |      |
queue    queue  queue
  |       |      |
user     user    user
  |       |      |    

So, the thing I don't like here is the three /|\, which means un-merging
of events in user code: I need to filter through all pending events and
move out the ones which are for me - instead of simply taking the events
from the queue one by one.

In the lower design, the queues would be real queues even with multiple
windows: I simply take the topmost item whenever one is waiting.

Of course, in case the user *wants* to handle a single event queue, the
designs looks like this:

    X11-events       
xwin   xwin   xwin
  |       |      |
AL_DP1   AL_DP2  AL_DP3
  |       |      |
 global keyboard queue
          |    
         user    

     X11-events       
xwin   xwin   xwin
  |       |      |
AL_DP1   AL_DP2  AL_DP3
  |       |      |
 queue   queue  queue
  \       |      /
         user  

Here the upper design works good. The lower design works basically the
same, since merging queues is no problem unlike un-merging (attach all
three keyboard event sources to the same queue).

Anyway, I'm fine with the upper way as well, the rate of keyboard events
probably is low enough that no matter how often you filter the queues
for events from a specific AL_DISPLAY it won't have a performance
impact, at least if you use less than 10 windows or so :)

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

This sounds a lot like "hack" to me. Unlike in 4.2, I would at least try
to do things in standard ways as much as possible for the next version,
i.e. update the design to what OS and users expects, instead of forcing
things. So yes, reading keyboard/mouse without a window probably is
possible somehow.. it doesn't mean it's a good/robust way to do things
though.

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

Well, the global AL_KEYBOARD. Was just repeating to myself how it works
at the driver level - each one attaching to it.

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

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

> > 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, I don't see that. For someone doing a one-window program, it does
not matter. And someone who does use multiple OS-windows certainly wants
to behave them like OS windows.

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

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.

> > - and some people think threads are evil.
> 
> Yet I still keep coming back to them :-)

Yes. And with the 4.2 design, there is no way to do it without, since
all events simply are asynchronous. But at least with the X11 port, it
would be possible now to not use them and instead 'poll' the OS event
queues whenever the user polls the Allegro events.

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

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

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

Yes, as I said, it seems hackish though. If each program I have
currently running here would see all keybord events, no matter who has
focus, it just would give a big mess - instead of writing this email,
the same keys might be intercepted anywhere and by a little coding
mistake in another app it would actually interpret them (a key logger
being about the only legitimate reason to do it). The OS/WM already
dispatches the keys to windows, and the user expects that, so if our
design would follow that as well, we can't go wrong.

-- 
Elias Pschernig





Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/