[ Thread Index |
| More lists.liballeg.org/allegro-developers Archives
On Sun, Jul 10, 2011 at 7:20 AM, Elias Pschernig
> There's probably no easy way. From what I remember you can get a
> GdkWindow for an external window from its X11 id and then maybe get a
> GtkWindow from the GdkWindow but it means a lot of messing around. I
> never tried though.
I was able to get a GdkWindow easily enough, but there did not seem to
be any way to get at a GtkWindow container from that. I don't see how
there would be a way, unless you could create a new GtkWindow, and
then take over an existing GdkWindow window (which would somehow nuke
the native frame).
> Hm. The clean way to do it likely would be to have a GTK system driver
> instead of the X11 one. So instead of the X11 event thread we run the
> GTK main loop and handle GTK events. Also would solve the problems you
> mentioned in your previous post. And al_create_display would then open a
> GTK window with an OpenGL view (and possibly a menu bar) inside.
> But yeah, instead of just writing some menu code, you'd write a complete
> GTK system driver now...
I've got the menu code all working, so I'll probably just commit it
as-is. It's goofy to have a second window for the menu, but if you're
just writing a quick & dirty utility, you may not care much. And if
one is bothered by that, he could just have the entire main menu bar
be a popup menu on Linux.
I think a GTK system driver would be useful, not only for the native
menu support, but also as a way to simply use GTK yourself. I might
look into it.
As you also mentioned, we could also simply provide an easy way to
plug the opengl context into something else. That's definitely useful
in a variety of ways. But I think a lot of people (in relation to
using menus) would prefer a GTK system driver as it means they don't
have to learn any other API. Even though it's not really that hard,
people are a bit strange about things like that. (e.g., People who
happily use an ALLEGRO_THREAD may have never bothered to mess with