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.
Specify behavior of help window in the new windowing system. The specification of help window integration described in the windowing system UI spec is rather vague. It should be enhanced and completed.
The UI Spec (not implementation) for help integration should be completed before the merge.
This comment contains the high level sketch of how the help system should be integrated with the new windowing system to provide the best user experience. The sketch is based on John-Jullion's document (URL is in the URL field), specifically on the internal solution for help presentation: http://usersguide.netbeans.org/proposals/help_windowing.html#internal This proposal is a slightly different. The help window should be divided into two separate parts - Help Contents and Help Browser. Help Contents would contain three tabs - Contents, Index and Search. Help Browser would show the actual help page and toolbar for back and forward navigation. - The Help Contents window would be a "view" in the windowing system terminology. It means it would be opened around the document area. - The Help Browser would be a "document" window. It means it would open inside the document area. The Help menu would contain "Help Contents [Ctrl+Shift+F1]" menu item which would open the Help Contents window on its default location. Clicking or selecting any help item in the Help Contents window would open (or bring to focus if already open) the Help Browser window. The contextual Help invoked with F1 keystroke within the main IDE window would open the Help Browser window. The contextual Help invoked from a modal or non-modal dialog would open a separate non-modal help window parented to the dialog. This special help window would be the same as in the current windowing system (NB 3.5.1). The Help window would be dismissed when user closes the original dialog the help was invoked from. (This might introduce a problem when user is following a recipe of how to solve something and the recipe requires to close the dialog. It might look strange that the help window is closed in such situation).
The complete specification of the Help integration with the new windowing system should be planned and provided separately. In the first phase of windowing system reimplementation, we should assure that the new windowing system doesn't cause a regression in help presentation. I am removing this from the tasks required for the merge.
Jano, do you have an idea of where the help navigators ("Help Contents" in your terminology) would appear relative to other "view" windows and which view windows would typically be open? Similarly, do you have an idea of where the Help Browser would typically be? Would it cover everything else in the document area, or would it have it's own place? If you could do a quick mockup of what the IDE might look like with the help and java file open for editing (or maybe even a java form), that would give the help writers a better point of reference. Thanks.
The issue #36119 contains the list of all windows and their location in the new windowing system. If the Help Navigator is implemented, then it should be displayed in the Properties "Mode" (look into the mentioned issue for more details). The Help Browser should be open in the center of document area by default. I will attach a quick mockups.
Created attachment 11833 [details] The Help Browser and Help Contents in the default layout.
Created attachment 11834 [details] The Help Contents window in gui editing layout.
Jano, I like this solution a lot, think it's definitely an improvement over current situation. One of the more problematic cases is where a user is following a procedure help page that makes her open several dialogs. The page is open in the Document area, then she opens a dialog and can't see it, so she clicks the Help button to get the floating Help window. But the Help button has a CSH topic that is probably different than the one she was using. This means that the help viewer for dialogs must have back and forward navigators. It should probably also have the navigation panels (TOC, index, search). Likewise, the help viewer in the document area should probably also follow the content of the dialog help viewer. That way when the user closes the dialog, the dialog help viewer is dismissed but she can still see the topic in the document help viewer.
Yes, that is the drawback of internal help window approach. The solution you mentioned is probably a must. We might also try to minimize this problem by guessing that the user is reading the internal help window and when she opens a dialog then automatically popup the external help window. For example, if the internal help window is visible and the user invokes a dialog, then do it? The opposite way (the user invoked help window from a dialog) would be probably impossible, as I don't see a way how to guess that the user needs the help window even after closing the dialog.
The Help window is now separated from the main IDE window. Please reopen if still valid.