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.
The Online help window is very irritating in that it opens up when using the IDE and gets in the way - especially when using the IDE in MDI mode. Can the Online help be executed separately from the IDE, in a menu on its own and also can be launched from the IDE?
Not currently, and probably not so easily.
FYI. Running in the help in a separate process is one solution we (various help writers) have talked about and generally like. Another idea is to better fit the help system in the IDE's window system when it gets redesigned some time post-4.0. We don't have the engineering resources to implement either of these ideas at the moment, but we hope to get these resources for a future release.
FYI - launching help in a separate process should not be hard, but communication with the parent is the headache: - NB-internal URL protocols like nbdocs: or nbresloc: need to be served to the external viewer, either using the internal webserver (introducing a major dependency) or manually (a headache) - need a command protocol to request it to display new help IDs - cleanup code to shut down the external viewer when NB shuts down - error-handling in case the viewer process dies unexpectedly... Basically this introduces a bunch more failure points. Also it would make initial help display rather slower, since a new VM must be forked which cannot reuse classes from NB. I am not sure what you mean by "it opens up when using the IDE and gets in the way - especially when using the IDE in MDI mode." What specifically happens that you think is incorrect (give exact list of steps please as well as details of your window manager)?
If Help is open and I want to use CVS is one example. When the various CVS dialogs open, Help fronts and I can't type in the text edit since the focus is on the Help window. Also, the Help window which opens along with the dialog, doesn't have a minimize button. Instead, if I want to minimize it, I have to click on the Close button of the dialog and choose the Minimize menuitem. Here's some steps where Help "gets in the way" 1) Open Help->Contents 2) Mount a CVS filesystem 3) Select the CVS filesystem and choose CVS->Add from the popup. The Help window fronts and grabs the focus from the CVS Add dialog.I have to select the CVS Add dialog. 4) Create a new folder Again the Help window fronts and grabs focus. I have to select the New Folder dialog before typing. Basically for every dialog that opens, I have to select it before typing. This can be annoying when doing CVS operations on a filesystem or creating new objects. 5) Before creating a new object (which opens a dialog), minimize the Help Window 6) Create a new folder Help window fronts again Alternatively, can the online help open in the user's default browser? The user can take care of closing the Browser?
Actually, on Solaris, dialogs don't have a minimize menu. So, I have to lower or close Help. Lower, also lowers the IDE. In some occasions, dialogs don't move to the side of the Help dialog, so the Help dialog has to be moved to the side. Minimizing Help shouldn't restore Help. If I want to restore Help, then can a menuitem be added to the Window menu for Help?
"The Help window fronts and grabs the focus from the CVS Add dialog. I have to select the CVS Add dialog." - yes, this is a known problem on some window managers, I think already filed elsewhere. I tried for a while (without success) to force focus onto the dialog. Just didn't work for some reason; I don't understand AWT enough to know why. Recommended workaround: close help window if you are not actively reading it. Anyway it should be straightforward to have it open to the same page it was on before (currently this is true only if you *don't* have the usersguide module installed, *and* you use Help | Contents to view help pages). Alt-H C is a pretty quick way to reopen it when you want it. I think I tried once to make the help window not appear in nonmodal dialog form when it was minimized to begin with, but got into some kind of problems - don't remember what, but I think some unexplained exceptions from AWT, probably due to some bug elsewhere in NB. Opening help in the web browser is not going to work too easily - there would be no navigation. (JavaHelp provides a TOC, index, search, etc., none of it available from the HTML.) There was a prototype of a JavaHelp servlet which could be used to serve live navigable JavaHelp to the web browser, but this was never released in legally usable form as I recall - may be a JH 2.0 thing, Tim can check on it. The other idea being floated around is to open help in a tab in the active modal dialog, rather than as a separate reparented nonmodal. Would have its own problems, but surely fewer than the current system. FYI the root of the evil is that there is (apparently) no way in AWT for an application to request that a particular frame - here, NB & JavaHelp - to be treated as part of a separate app context, and thus not subject to blocking from modal dialogs in the main app context. If there were such a system, we would use it in a moment and greatly simplify the windowing behavior of the help system. Unfortunately this feature does not seem to exist.
fixed for jdk1.5.0_03/_04 we can exclude help frame from modality. this RFE is irrelevant