Re: [AD] native menus

[Matthew Leverton <meffer@xxxxxxxxxx>]

On Wed, Jul 13, 2011 at 10:10 AM, Evert Glebbeek <eglebbk@xxxxxxxxxx> wrote:
> That's actually why I was thinking of storing the information in Allegro's OSX_DISPLAY structs: the information can then be set automatically when the display is switched in. There may be some caveats I didn't think through fully.
>
The addon already uses a display/menu struct vector in the native
dialog that can be queried to get at the attached menu. I would have
liked to put it in the ALLEGRO_DISPLAY itself, but it felt like a
violation of how addons are supposed to work.

This is sort of off topic, but maybe it wouldn't be a bad idea for
Allegro to support some abstract (non-queued) event based
communication between the core code and the official addons. So the
dialog addon for OS X could do something like this:

void set_menu(void *event_data, void *user_data)
{
  ALLEGRO_DISPLAY *d = event_data;
  // the following functions are in the dialog addon:
  ALLEGRO_MENU *menu = _al_get_display_menu(d);
  _al_show_display_menu(d, menu);
}

_al_observe_core_event("display.switch_in", set_menu, NULL);

The OS X core allegro code would simply do this:

_al_emit_core_event("display.switch_in", display);

And that would cycle through all registered callbacks, passing both
display and the user data (NULL in this example).

This differs from queued events in that you know they are happening in
the proper thread and being processed in realtime. It could be
implemented by an as-needed basis, and I don't see any reason to
extend such code to the user.

Anyway, just a thought I had...

> By the way, we should preserve the default menu entries we create already (the Application and Window menu's) since they're supposedly standard...
>

Yes. The OS X would just silently insert them when the menu is built.

I think the only annoyance would be if the user already has a Window
menu. In that case, perhaps the default Window menu could be
appended/prepended to it after a menu separator.