NetLogo 3D on Mac OS X 10.6/7: menu items grayed out, unusable with mouse

[SethTisue]

WORKAROUND: Corey Brady discovered that you can re-enable the menus by opening a modal dialog and then closing it again. For example, a quick way is to press Command-M to open the Models Library dialog with Command-M, then press Esc key to dismiss it.

the keyboard shortcuts for the grayed out menu items still work, so it's clearly Apple's bug. though it would be good if we could find some kind of workaround to put in the code so users don't have to use the workaround above

a user reports that Mac OS X 10.5 works fine. it's broken on 10.6 and 10.7

both NetLogo 3D 4 and 5 are affected

[SethTisue]

I don't know how to work around this in our code. If anyone out there knows Swing and wants to take a crack at it, it would be much appreciated.

[SethTisue]

I wonder if this still happens in Oracle's Java 7 for Mac.

[nholbert]

This bug still happens in OSX 10.9.1 with 5.0.5

[SethTisue]

@frankduncan writes:

[this] apparently happens because the new 3d window is getting constructed on a thread that is not the event dispatch thread (it's hapepning in the modal dialogs thread). Are those all words you're familiar with? If yes, then you mgiht be able to tell me the netlogo method of ensuring that commands that open new models eitehr happen only on the event dispatch thread, or only creating the 3d view window on the event dispatch thread (perhaps via some other listener mechanism)

[SethTisue]

iirc, in Swing modal dialogs work a funny way, where the original event dispatch thread is suspended, and a new thread is created for the modal dialog, but for the duration of the dialog, the new thread is the event dispatch thread.

what's your evidence that this is a threading issue?

[frankduncan]

If I execute the new model action in the running thread instead of booting a modal dialog, it does not disable. Also

http://stackoverflow.com/questions/13754955/java-menu-on-mac-grayed-out-on-change-focus

[SethTisue]

checking isMac() and avoiding the modal dialog seems like a safe and reasonable workaround, then. although I'd like to see the diff you did so I could look at the change in context. it sounds to me like Apple's bug not ours, but maybe if I saw the relevant section of our code I'd think differently. (and even if it's Apple's bug it's of course still worth working around)

iirc for normal models the modal dialog during loading isn't really necessary, but some models might take a long time to load, e.g. if the world is really big (which is especially likely to be the case in 3D), in which case the progress dialog is nice to have, but not critical

[frankduncan]

Alrighty, after some more investigation, this is what I've found.

If the ModalProgressTask is not modal, everything works as you'd like. If we don't use the ModalProgressTask, everythings as you'd like.

And here's the kicker.

If, after letting the other thread come back, with the ModalProgressTask being modal, we then setVisible(true) on it again, starting up another thread that does nothing but return immediately and hide/dispose the ModalProgressTask, everything works as you'd like!

My best guess at this time is that OSX is doing something funny because the frame that gets focus (when opening a new model) after the modal dialog closes is the 3D view, something that has no menu items. As an aside, I attempted to also solve this by attaching the menu to the application in OSX, rather than to the JFrame, but that broke many things in many odd ways (does netlogo count on the menu being attached to the jframe for other purposes? That is an interesting question)

I'm currently leaning toward re-opening the modal dialog for zero time, as that keeps it nice and modal and has the best user experience.

The stuff about threads was, while highly informative as I looked all the stuff up, unfortunately a red herring.

[frankduncan]

As an addendum, I would only open the modal dialog for zero time if on a mac and in 3d mode, since that makes it clearer that this is due to odd behavior and shouldn't be removed.

[SethTisue]

sgtm

[SethTisue]

PR #622