ERSUCC
commented
1 month ago I tested the LevelSpace extension with the development version of NetLogo on my Mac, and the issue seems to be no longer present. To confirm that it wasn't just my system being strange, I tested on the same Mac with the released version of NetLogo, and the issue was present. I believe that I fixed the issue with pr #2286 (see MenuModel.scala). Could someone confirm that the issue is indeed fixed as it seems to be on my end?
brandesNW
If an extension adds an item to the main menu bar on macOS in NetLogo 6.3 or 6.4, when the extension is unloaded by opening a new, blank model or a different model by any means, the extension's menu bar item will remain. This can cause duplicates if another model using the same extension is loaded. The only way to clear the menu items is to close and re-open NetLogo. This was originally opened as an issue in the SimpleR extension repository.
This issue only affects macOS, both ARM and x86. This affects the LevelSpace, SimpleR, and Python extensions, and maybe others if they use a similar technique. This is a regression from 6.2 to 6.3, as in 6.2.2 (in LevelSpace, at least), the menu item removal is respected.
My research:
unload()event handler is getting called when the model is changed, and that the extension is removing the menu bar item (here is where the menu item is loaded). I confirmed that the backing collection of theJMenuBardoes reflect the change - it doesn't have the extension menu item after removal, but the UI doesn't update to reflect this. The Language-Library used by SimplerR and Python actually has code to detect and re-use an existing menu item, but because it's not in the backing collection it doesn't find it. A quick attempt toinvalidate()either the frame or menu bar didn't help.MacApplicationworks as expected (just doing anetlogo/runfrom sbt instead ofmacApp/run). So something about the wrapper class introduces the issue.apple.laf.useScreenMenuBarsetting from theMacApplication, just to see if that had an impact, and it did not help; the issue persisted.It's super-weird that the
add()method works fine, but theremove()does not, supposedly with the sameJMenuBarcomponent.Possible ways forward:
mac-appfolder from 6.2.2 to 6.3.0. The one thing I see that's suspicious is the swap of theApplication applicationbeing an argument to theMacHandler()constructor to instead being plucked from theDesktop.getDesktop()method. It's not immediately clear why this would matter, though.macApppiece altogether. It might no longer be required, as Java has better support for making native-appearing macOS applications than it did when this piece was introduced. This would require some build changes but would have the benefit of getting all platforms using the same code.I've run out of time to look further into this, hence why I'm opening this issue up here.
mac-app-6.2.2-6.3.0.patch.txt