This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
[ JDK VERSION : J2SE 1.4.2_02 ] On OS X there are six different ways to tell NB to stop running. 1. Choose File ==> Exit. 2. Type Option F X. 3. Click on the red close button. 4. Type Command Q. 5. Choose Quit NetBeans from the NetBeans menu in the menubar at the top of the screen. 6. Right click on the NetBeans icon in the dock and choose Quit. Choices 1, 2, and 3 cause NB to stop running properly. Choices 4 and 5 cause NB to stop, but when NB is started again, it complains that another instance of NB may be running. (Apparently these choices cause the equivalent of kill 09.) Choice 6 is totally ignored. Note - when OS X does a shutdown, it apparently uses choice 6, because NB keeps running and the shutdown eventually times out. Thus, NB must be stopped manually to shutdown the OS. Second Note - I believe this behavior was true with NB 3.5.1, as well. If needed, I can file a bug with Apple as well. However, unlike Issuzilla, no one outside of Apple can see the bug info. Background info: OS X 10.3.2 Java 1.4.2_03 NB 3.6 Beta
Reassigning to core.
Tim , I know you have the most of opened defects, but this issue is reported on Mac, so can you look at it please ? Feel free to reassigne.
Created attachment 13451 [details] Install the attached module (put it in $NB_HOME/modules) - it fixes the problem
I just attached a module written to solve this exact problem. It remaps Tools | Options, About and Exit to the right places on the apple Application menu. Just install it and this problem will go away. Note it does hide Help | About and File | Exit, but does not hide Tools | Options - the call to make Preferences visible on the application menu (using com.apple.eawt.Application) sometimes works, sometimes doesn't, so until they fix that (or I find a way to call it *very* early in startup), I don't want to make all access to Tools | Options vanish! Source for it is in contrib/osx-native-installer/applemenu if you're interested. Probably we should ship this module as part of the 3.6 release installer - it's quite harmless, and without it, Quit will always brutally kill NetBeans process. Note, if you're running using the NetBeans Launcher installer, you won't have a place to put this file; download a zip distro instead (or [shameless plug] if you have the netbeans sources, build an installer using contrib/osx-native-installer - I need people to test this!). Leaving this issue as TBD until we figure out what to do for 3.6 release - include the module or not.
Hi Tim, This works for me. I downloaded the attached jar file and put it inside the modules directory (inside the NetBeansLauncher). No more ugly dialogs about another copy of NetBeans running, and choosing Quit from the Dock works, too! From the original list of options: 1 and 2 disappeared, as described in the message below. 3 continues to work. 4 and 5 now shut down properly. 6 works (shuts down properly). Thanks very much Tim. Travis
Solution will be to include this module in the distribution of NetBeans for OS-X. No reason that can't be done for 3.6 - the total amount of code other than headers in the module is about 15 lines - nothing that couldn't be reviewed in time.
This is still not fixed in the RC1 release (build 200403141830), although the code to do this was available 02/20/2004. Please include the fix in the generic jar installer and the ide-EN.zip file. I just retested the fix attached to this issue with RC1 and it works just fine with this version also.
We're working on it. The main thing is that this module will not run on non-macs (no com.apple.eawt package), so we have to make sure it *doesn't* get installed on non-mac machines. I don't have anything to do with the jar installer, so I don't know what's possible there or not. BTW, I have written generic OS-X installer support, which is considerably nicer than the jar installer, but it needs to be tested. If I put an installer up, would you be willing to give it a try? (Note I'm not the person responsible for writing installers!) It will include the applemenu module automatically.
*** Issue 34244 has been marked as a duplicate of this issue. ***
I'll try to prepare MacOSX disk image with the attached applemenu.jar file included and will post you download URL.
Tim, it was my understanding that Apple described how to use the eawt to that it could be used on all platforms. This link talks about doing just that. http://developer.apple.com/ samplecode/Sample_Code/Java/AppleJavaExtensions.htm. Unfortunately, I personally don't have the expertise to help with this. Is there some other way I can help?
Rudolf, I will be glad to test that disk image. Just let me know when you have it ready.
Changed priority to P2. (Didn't know it was my responsibility to do so.)
a better sample from apple is http://developer.apple.com/samplecode/Sample_Code/Java/OSXAdapter.htm "The class is loaded using reflection, so that it will only be referenced by platforms that actually support the Apple EAWT. The built product should run unmodified on any Java implementations. Useful for developers looking to support multiple platforms with a single codebase, and support Mac OS X features with minimal impact."
I just looked at the applemenu.jar and I think that we should not remove 'Exit' and 'About' from NetBeans main menu as applemenu.jar does. It makes sense when we will run with screen menu enabled, but currently it looks strange. I propose that 'Exit' and 'About' will remain in NetBeans Main menu.
Does it mean Trung that you plan to fix it in the release36 codebase rather than include the additional module in the Mac OS X disk image as Rudolf proposed ? I would like to stress that this defect must be fixed in 3.6 because it has 15 votes which meets criteria for considering a bug as showstopper according to NetCAT program guidelines.
deeptinker, we have some MacOSX disk image the applemenu.jar attached to this issue, but I guess, that the change in menu is unplanned and was not discussed with UI guys. Although the MacOSX disk image with applemenu.jar is in fact already 'invisibly' available on netbeans.org website, I would like to keep the download URL private until we clear this UI issue.
Created attachment 13994 [details] AppleMenu module that does not hide menu items
I've attached another version of the applemenu module that does not hide menu problems. We can debate which is stranger UI - duplicate menu items, or making the help inaccurate by moving menu items - later - probably a question for the HIEs. Deeptinker: There is a fairly heavyweight legal review process needed to host any binary that is part of the build process on netbeans.org - probably we should do that for the apple stub library at some point, but it takes a while to do. Also, in 3.6, the module specification doesn't include any way to specify identifying a module as platform-specific. There is a proposal to do that, so once that's done, we'll be in better shape to deliver things like this via the update center, etc.
Trung - Thanks for the additional example. Tomas - L&F issues are important, but not as important as the first time user having a positive experience. Tim has created another module that addresses your concerns so the community can choose. Tim's first module is more "Mac-like" per Apple's HI guidelines, but as long as one of these modules is included in the final release I will be happy. Rudolf - I tried the newest installer that appeared (NetBeansIDE-release36 -200403141830-MacOSX.dmg) but it did not contain an applemenu.jar in it, so it exhibited this problem. The good news is that adding either of the applemenu.jar files works perfectly. Tim - Thanks for such a rapid response to the concern expressed by Tomas. I see your point about the legal issues. Apple is well-known to be a heavyweight in this area, which we don't need this late in the release cycle. Will including your jar file in just the Mac installer avoid this? All - My concern here was only that this issue, which already had a fix, was somehow being overlooked, and would not make it into the final release. Since OS X installers are (or were) not included in the daily builds, I had no way of verifying that this fix was included.
deeptinker, the build you've tested is public, the build I was referring to is still on unpublished URL. There were MacOSX disk images in daily builds during last week, but w/o applemenu.jar added. My personal vote (even I'm not a Mac user) goes to make menu items duplicated. My opinion is based on two points: 1) I prefer to have as much as possible the same IDE on any platform 2) when Mac user reports new issue, it would be strange to ask him/her to "copy-paste" information from window box invoked using menu item Help|About I will rebuild the MacOSX disk image and will let you know where you can get it.
Agreed. Once the screen menu bar actually works correctly (the core problem is that our lazy menu initialization depends on getPopupMenu() being called before the menu is shown, which is not true for apple's screen menu implementation), it might make more sense to remove the menu items; for now, having some menu items in the screen menu and others in the main window's menu doesn't make sense.
And yes, there's no problem including the module in just the mac installer (probably should be some mention in the release notes that if someone gets the zip distribution, they should get this module too).
Isn't there also going to be some kind of installer for Mac that this might be included in? Also, will the module be added to the Update Center?
Can't put it on the update center for 3.6 - there's no way to specify that a module should only be visible/loadable for apple users. I could put some test into the moduleinstall (I forget, maybe I already did) that won't allow it to install if it can't find the apple extension class it uses, but probably better just to not expose it.
Folks, MacOSX disk image with the second applemenu.jar is available from following URL: http://www.netbeans.org/download/release36/test/200403151830/release36-build-MacOSX-installer.html Please give us feedback for this solution, whether it's acceptable to make it happen in final release of NetBeans IDE 3.6. Please note, that I'm just a release engineer who is trying to help and checking possibilities, so please do not treat this comment is any kind of promise we'll go this way.
Rudolf, I tested the installer noted above and it works beautifully. It includes the duplicate menu picks as you and Tomas requested. Thanks for making it available. How many more people do you need to test this installer to raise the comfort factor to an acceptable level for the release? Travis
Hi all, The first time i ran NB (v RC1 build 200403151830), when it opened the ide i got an exception immediately. I quitted from NB and ran it for another 3 times, everything went well. When i looked at the message carefully it seems to point to the UpdateCentre and when i invoked Tools/UpdateCentre it gives me an exception, after that it seems i cant invoke Update Centre anymore. Below is the exception i got from the first run. Annotation: Missing resource from class: org.openide.util.NbBundle$PBundle Annotation: Key which was not found: URL_Default_Alpha java.util.MissingResourceException: Can't find resource for bundle org.openide.util.NbBundle$PBundle, key URL_Default_Alpha at java.util.ResourceBundle.getObject(ResourceBundle.java:314) at java.util.ResourceBundle.getString(ResourceBundle.java:274) at org.netbeans.modules.autoupdate.XMLAutoupdateType.getDefaultURL(XMLAutoupdateTyp e.java:289) at org.netbeans.modules.autoupdate.XMLAutoupdateType.readObject(XMLAutoupdateType.ja va:329) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:838) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1746) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1646) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:324) at org.netbeans.modules.settings.convertors.XMLSettingsSupport$SettingsRecognizer.readSe rial(XMLSettingsSupport.java:515) at org.netbeans.modules.settings.convertors.XMLSettingsSupport$SettingsRecognizer.instanc eCreate(XMLSettingsSupport.java:543) at org.netbeans.modules.settings.convertors.SerialDataConvertor$SettingsInstance.instanceC reate(SerialDataConvertor.java:350) at org.openide.loaders.FolderLookup$ICItem.getInstance(FolderLookup.java:470) at org.openide.util.lookup.AbstractLookup$R.allInstances(AbstractLookup.java:696) at org.openide.util.lookup.ProxyLookup$R.computeResult(ProxyLookup.java:369) at org.openide.util.lookup.ProxyLookup$R.allInstances(ProxyLookup.java:320) at org.openide.util.lookup.ProxyLookup$R.computeResult(ProxyLookup.java:369) at org.openide.util.lookup.ProxyLookup$R.allInstances(ProxyLookup.java:320) at org.netbeans.modules.autoupdate.AutoupdateType.autoupdateTypes(AutoupdateType.jav a:67) at org.netbeans.modules.autoupdate.ServerPanel$ServerTableModel.refreshContent(ServerPa nel.java:178) at org.netbeans.modules.autoupdate.ServerPanel.<init>(ServerPanel.java:47) at org.netbeans.modules.autoupdate.AutoCheckInfo.<init>(AutoCheckInfo.java:74) [catch] at org.netbeans.modules.autoupdate.AutoChecker.run(AutoChecker.java:97) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:178) at java.awt.EventQueue.dispatchEvent(EventQueue.java:454) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:234) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java: 184) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:178) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:170) at java.awt.EventDispatchThread.run(EventDispatchThread.java:100)
Cheong, looks like you just ran into the showstopper for the RC1. See http:// www.netbeans.org/issues/show_bug.cgi?id=41020. Per the issue log, a fix is already on its way. Travis
Travis, we discussed this with Jirka Kovalsky and agreed, that I'm not in charge to set any such limits. It's political/strategic decision, where I do just technical advisory service.
Proposed relnote: If you install an archive distribution of the IDE on Mac OS, typical ways of shutting down the IDE do not work properly, which could cause problems such as: * losing work if you do not manually save changes before exiting the IDE * upon starting the IDE again, getting warnings that the IDE is already running Workaround: Download and install the .dmg image distribution of the IDE, which has a patch to solve this problem on Mac OS.
Hi all, I've reuploaded MacOSX disk image for RC1. The NB 3.6 RC1 has got the applemenu.jar module patch inside.
I encountered some situation which i m not sure if this is a feature or bug but i think it is more of the latter. There are sections named "Expected behavior", those are only my view about what an expected behavior should be which may differ from the actual designed behavior :) Btw, what raised is not a showstopper to me, i can live with it as i have learnt to live without this quitting feature in the past :) Below are my scenarios - 1. System Shutdown without unsaved modified file After NB has launched and i decided to shutdown my machine, i activate a system shutdown Ctrl-Eject, I received a Info panel with the following message :- "The application NetBeans cancel shutdown. To try again, quit NetBeans and choose Shut Down from the Apple menu". The strange thing is, NB was forced to quit only the NB Launcher is still alive. If i would to do another system shutdown again with only NB launcher hanging around, the system shuts down smoothly. Expected behavior : Both NB and NB Launcher should exit quietly when there isn't any unsaved modified file and OSX continues with shutdown. 2. System shutdown with unsaved modified file Do a shutdown while i had a modified file unsaved, NB pops up a "Save" panel asking for decision to handle unsaved modified file and OSX pops up panel with the message "The application NetBeans cancel shutdown. To try again, quit NetBeans and choose Shut Down from the Apple menu". If i select from NB's "Save" panel, the Cancel button, NB remains open If i select "Discard All" or "Save" or "Save All" button, NB quits, NB launcher remains alive but OSX shutdown is cancelled. Expected Behavior: Cancel seems to have the right behavior, but the rest of the other options in the "Save" panel should allow system shutdown to carry on after saving or discarding the file.
Adding Tomas to cc - issue with the launcher application. Note: It sounds like you may be running NetBeans directly from the disk image, I'm not sure. It is best not to do that - performance is significantly slower if classes are being loaded from a compressed disk image.
Hi Tim, I am not sure if you were asking if i were running everything off the disk image? Answer is no. I apologize for not stating my environment. I had NB installed in my Desktop not Applications folder mainly because i am pure lazy and you can tell by the fact that i normally do a System shutdown to quit all my apps at one go :). My os is 10.3.3, java v1.4.2
I will look at the problem with System Shutdown.
This issue is listed in the release notes as a known problem. The workaround is incorrect, however. The patch is NOT included in the .dmg image. I'm willing to modify the release notes to point to the link to the jar file (given above) and add instructions for installing it. I tried to find the source for the release notes at http://www.netbeans.org/community/releases/36/relnotes.html in cvs, but was not adept enough to find it. If someone can nudge me toward the right trunk/branch and directory, I will checkout a copy and make the changes (for someone else to review, of course). Travis
Oops, mea culpa, mea maxima culpa. I'll fix it asap.
The MacOSX disk image has been reuploaded. It now should contain the applemenu.jar fix. FYI: I made buildsystem change to prevent this error again. Further MacOSX builds (for 3.6 multilingual builds) should get the applemenu fix automagically.
FYI, I made some changes to the applemenu module last night - I got an answer from an Apple JDK engineer about why the Preferences menu item sometimes didn't get enabled (the code to enable it checks Beans.isDesignTime(), so it would work if applemenu got loaded before the form editor, and wouldn't if it got loaded after the form editor). I'll attach a new version of it for the current trunk.
Created attachment 14385 [details] The now-projectized applemenu module
Hi Rudolf, Thank you, thank you, thank you! I have redownloaded the OS X installer and verified that it works as expected. Hi Tim, After testing Ruldolf's new installer, I removed applemenu.jar from modules and dropped in the org-netbeans-modules-applemenu.jar attached above, and it worked as expected also. What happens next? Am I supposed to mark this issue fixed? Does it need more testing by a third party? Does it need to wait for confirmation from Rudolf that the projectized jar file hass been put in the installer? Something else? Thanks both of you, Travis
Good question. It is fixed for 3.6, with the module, so I suppose it's a matter of taste - should it be marked fixed if a standard build won't get you an apple-friendly module, you need to build applemenu (on a mac) in order to do it.
*** Issue 42025 has been marked as a duplicate of this issue. ***
Okay, I'm marking this as fixed. Rudo, are you *sure* there is some infrastructure in place to cause huge alarm bells go off, and large animals to devour the buildmaster if anyone building a release distro of NetBeans forgets to include this module in the future? :-)
perhaps we'll put this module in the standard build of NB 4.0. Let's see
I moved the applemenu module to ide/applemenu and included in the standard NB 4.0 build
v/c
This issue had *8 votes* before move to platform component