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.
Summary: | Help window should display contents of currently open modal dialog | ||
---|---|---|---|
Product: | platform | Reporter: | David-john Burrowes <davidjon> |
Component: | Help System | Assignee: | mslama <mslama> |
Status: | RESOLVED WONTFIX | ||
Severity: | blocker | CC: | pkeegan |
Priority: | P4 | Keywords: | UI |
Version: | 3.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Bug Depends on: | |||
Bug Blocks: | 29448 |
Description
David-john Burrowes
2001-11-13 23:54:44 UTC
Target milestone -> 3.3.1. Set target milestone to TBD Set target milestone to TBD Wrong component. You're as likely to work on these as I am not, I guess. I have no time for core/javahelp development. Maybe you will at some point. More useful summary. David John, I just wanted to check in with you to see if you've thought any more about this issue. IMO, the enhancement you suggest would be useful in certain use cases but a nuisance in others. I think it would work well if the IDE had a concept of a permanent dynamic help window whose content changes depending on context. See issue 35028, which asks for a window that presents a changing set of help links based on context. However, as the help system in the IDE is currently constituted, I think having dynamically changing content could be infuriating. Imagine the user who opens the help to accomplish a task that requires the traversing of multiple dialogs, which I think is a fairly common use case. I don't think these two use cases are necessarily incompatible, but we need to reconcile them somehow and I'm very curious if you have any ideas about this. Well, actually the problem and solution I spoke of in the original issue seem to have been more of a suggestion to improving that particular situation in a small way. Removing the floating help window entirely would actually be a better solution to the problem (but, less "incremental" :-) The "real" problem here was just that the window would appear as if it were saying something relevant, but it wasn't. so, removing it from saying anything at all is just as good as making it say something relevant, I think. As JDK will provide us with way to exclude Help window from modal loop Help window will not change its status (moving, closing, fronting) when modal dialog is opened/closed. I think if user opens any dialog or changes his context he can use F1 anytime to refresh/change context in Help window and front Help window. I do not like idea to automaticaly change content of Help window according user context in IDE (or in other words according to what is user doing). It might be appropriate in some moment but I think it is harmfull in more cases. See for example issue #41378 (and there is more similar) It is result of current workaround to keep Help window enabled when modal dialog is poened. (Workaround is to change owner of Help window to modal dialog - it keep Help window enabled but has many annoying side effects.) Closing this as WONTFIX. |