NetLogo 3D on Mac OS X 10.6/7: menu items grayed out, unusable with mouse about netlogo HOT 11 CLOSED

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.

from netlogo.

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

from netlogo.

This bug still happens in OSX 10.9.1 with 5.0.5

from netlogo.

@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)

from netlogo.

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?

from netlogo.

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

from netlogo.

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

from netlogo.

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.

from netlogo.

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.

from netlogo.

sgtm

from netlogo.

PR #622

from netlogo.