Re: [AD] ex_menu crash in Windows

[Peter Wang <novalazy@xxxxxxxxxx>]

On Thu, 24 Nov 2011 08:34:17 -0700, Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx> wrote:
> On November 24, 2011, Evert Glebbeek wrote:
> > On 24 Nov 2011, at 13:58 , Peter Wang wrote:
> > > Ok, did that, or at least made a start.  We'll probably want a way to
> > > create an unmapped window to embed elsewhere.  I just ran an Allegro
> > > program, then got the window ID out of allegro.log and passed it to
> > 
> > > socket.py from:
> > I only skimmed the documentation, so I may not understand completely what
> > this does. Do I understand correctly if I think that this allows us to
> > create an X11 window with Allegro, then pass the window ID to GTK (or Qt,
> > or whatever) as well tell GTK how to request mouse/keyboard data from
> > Allegro. GTK is then able to draw a menu on the window we created with
> > Allegro, and send messages back to Allegro if the menu has been
> > clicked/otherwise interacted with? If so, that's pretty cool (do we need
> > to enlarge the window to fit the menu?). If not, how far off am I?
> 
> I thought it was more like you could embed the allegro window inside any other 
> X window.

Right.  So you can create an Allegro window and make it appear within a
GTK window (for example) by using the GtkSocket container widget.
The Allegro window and the GTK window would have separate event loops,
and may be in separate processes.  There's very little coupling.

Actually, just visually embedding a window did not require implementing
the XEmbed protocol.  Being aware of XEmbed should take care of some
things, e.g. when tabbing through a GTK application, it can pass focus
to the Allegro window.  Currently you can't tab back *out* again, though.

> But you may be right, if you can get gtk and qt to embed our window, 
> whats to stop it from allowing us to embed a menu?

That's probably less useful and more work.  We'd have to implement the
other side of the XEmbed protocol (to act as the embedder).

Peter