[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On Mon, 17 Dec 2012 21:35:18 +1100, Peter Wang <novalazy@xxxxxxxxxx> wrote:
> On Mon, 17 Dec 2012 01:08:43 -0700, Trent Gamblin <nooskewl@xxxxxxxxxx> wrote:
> > On 2012-12-15, at 4:31 AM, Peter Wang <novalazy@xxxxxxxxxx> wrote:
> > > Hi,
> > >
> > > I'm not completely pleased about GTK turning into a dependency of the
> > > core library. Even though it can be compiled out, the nature of Linux
> > > distributions means that it *will* be compiled in. I really don't like
> > > the idea of all keyboard and mouse input being filtered through GTK,
> > > even in programs which won't use the menu support nor even the native
> > > dialogs addon.
> > >
> > > It seems like it should be possible to move the GTK dependency back out,
> > > leaving hooks in the core to be filled by the native_dialog addon when
> > > it is actually used (e.g. setting an auxiliary system vtable pointer or
> > > something). We don't already have an al_init_native_dialog_addon
> > > function, but that would be the obvious place to do it. The user would
> > > be required to call al_init_native_dialog_addon before create the
> > > ALLEGRO_DISPLAY. Programs which don't link with the native_dialog addon
> > > on X11 would go back to working as if GTK support were compiled out.
> > >
> > > What do you think?
> > >
> > > Peter
> >
> > So would this be something like this in the display driver instead of
> > compile time checks?
> >
> > if (al_native_dialog_addon_inited()) {
> > gtk_vtable = system->get_native_dialog_data();
> > gtk_vtable->do_something(...);
> > }
> > else {
> > /* Normal GLX code that's always been there */
> > }
>
> I was thinking that the GTK backend would call a private function
> in al_init_native_dialog_addon(), e.g.
>
> _al_xwin_set_aux_interface(ALLEGRO_XWIN_AUX_INTERFACE *vtable);
>
> which sets a global,
>
> ALLEGRO_XWIN_AUX_INTERFACE *_al_xwin_aux_vt = NULL;
>
> Then where the GTK-specific behaviour is required,
>
> if (_al_xwin_aux_vt && _al_xwin_aux_vt->do_something) {
> _al_xwin_aux_vt->do_something(...);
> }
> else {
> ...
> }
>
> I think the hard part will be trying to reduce the amount of X port
> internals leaking into the native dialog addon.
Ok, I did something like what I suggested.
Sorry if I broke the Raspberry Pi port in the process.
As I wrote, I'm still not too happy that a program which only wants
message boxes will be forced to go through GTK for input (assuming we
can get the GTK paths working as well as the normal Xlib paths in the
future).
I'm thinking we should do as somebody suggested, and add a display flag
like ALLEGRO_GTK or ALLEGRO_GTKGLEXT. You would need to set that before
creating the display if you want menus.
Peter