Re: [AD] native menus

[Matthew Leverton <meffer@xxxxxxxxxx>]

On Tue, Jul 5, 2011 at 7:34 PM, Matthew Leverton <meffer@xxxxxxxxxx> wrote:
> I've committed the Windows implementation for the native menus. I'll
> add the docs and update MSVC's unfriendly tab formatting a bit later.
> ex_menu.c is a quick demo that shows some of the API.
>
I've committed the user docs.

I poked around the GTK code and it looked like too much hassle for me
to bother with at the moment, given how it looked like each of the
functions would need to be implemented like:

* create struct
* fill struct with parameters
* pass struct to GTK thread
* wait for thread to finish
* return

Also, the refcount for when to enable/disable the GTK thread might be
a bit hard to maintain now. If the thread is only active when a menu
bar is present, then that means you have to queue up all changes to
detached menus and create / update the GTK structure at the point of
when a menu is attached to a display.

It might not be as bad as that sounds, since the changes are already
stored in the ALLEGRO_MENU structure. Basically, you'd have to just
totally recreate the entire menu every time it is attached. (And if
the menu is currently attached while it is modified, then update it
directly.) The functions would just have to lie and return true
prematurely under the assumption that the menu will be created. But
that's not a big deal, because it could still return false when the
menu is displayed.

But there's also the case of a popup menu. There's no telling when it
will be displayed, so you'd definitely need the GTK thread around
while there is at least one popup menu. It might just be simpler to
let the user manage this by calling al_init_native_dialog_addon() [a
function I added] and later just uninitialize it when he no longer
needs it [that function does not yet exist].

Right now each menu_item and menu struct has an "extra1" void
parameter that can be filled into be anything. That's all that was
needed to implement it under Windows. (Actually menu_item->extra1
wasn't even needed.)

The core code is not thread-aware right now, which obviously could
cause problems. But it doesn't bother me to simply put the burden on
the user not to update the menus from multiple threads at the same
time. (Although they should be able to update the menus from any
particular thread.)

The only major caveat that I came across in Windows is that the menu
bar eats up some of the client space. A resize event is triggered. If
ignored, then the aspect ratio is flattened (at least under D3D). If
acknowledged, you lose some space. It's trivial for the user to catch
the event and upsize the window if needed. ex_menu.c does this. I
worded the documentation to say that space may be lost... so if it
doesn't really matter what happens under GTK, as long as a resize
event occurs if space is lost.

At least this is the one thing that the OS X implementation doesn't
have to worry about...

For OS X, the nicest hack for multiple menus (multiple displays) would
be that upon switching to a new Allegro display, the system menu is
automatically destroyed and created fresh based on what that
particular display has set for a menu.

--
Matthew Leverton