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 viewer update umbrella | ||
---|---|---|---|
Product: | platform | Reporter: | _ wadechandler <wadechandler> |
Component: | Help System | Assignee: | Jaroslav Havlin <jhavlin> |
Status: | NEW --- | ||
Severity: | blocker | CC: | av-nb, jglick, pkeegan, tboudreau, vieiro |
Priority: | P3 | Keywords: | UMBRELLA, USABILITY |
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Attachments: | Bad link fomatting |
Description
_ wadechandler
2008-12-11 20:39:22 UTC
Most of this will sort of end up under the umbrella of JavaHelp enhancements. Personally, I wouldn't mind seeing us move away from using JavaHelp, as it's appearance is a bit long in the tooth and something browser based would probably work just as well. What do you mean by browser based? A help system in the browser? Do you envision it having panels, search etc? That wouldn't seem very integrated though. I know from an RCP perspective folks really wouldn't like that; I wouldn't. Too, I think with the browser bits you wind up having a bunch of pieces such as some kind of an embedded server or applets or something to perform the search and retrieval bits. How do you envision this all working and being integrated? So, assuming this a feee-for-all on current JavaHelp, one things the really bugs me about the current JavaHelp based implementationis handling external links. Links with a relative URL to a document within the help system work fine. But as soon as you need to link to external links and open that in external browser there is no good way of doing this. <object classid='java:org.netbeans.modules.javahelp.BrowserDisplayer'> tags allow this, but the formatting is horrible (links appear with high base line, and if used in line with other text cause huge formatting problems). I will attach screenshot with example. Surely a more HTML friendly approach is called for. Created attachment 74870 [details]
Bad link fomatting
Cc'ing Jesse since he's had an interest in the past, and Patrick because a doc-writers perspective on this is very important. Personally my main objections with JavaHelp are just that the viewer is ugly, has "border build up" problems and generally looks like something a Windows 3.1 programmer would love, so it's kind of an embarrassment from the UI perspective. It is, for whatever it's worth, controlled by a set of UI delegates just as regular Swing components are, so some of that could be done from the NB side if anybody deemed it worth doing and wanted to maintain the result in perpetuity or get it into the JavaHelp source tree (a scary place - I projectized it for the OpenJDK launch). Thanks for filing this Wade. The help system has bugged me for a while (I put it down to me being a dumb user) and I have often resorted to Google search in preference, so perhaps the browser based solution would be appropriate (although it would be useful if it could be (optionally) available off-line). Incidentally, the number relates to the number of matches in the corresponding document-nothing to do with chapter/book, etc (the more matches, the higher up the pecking order). Current Help Window UI looks 'outdated'. And we either should get rid of JavaHelp or invest much in changing its UI in order to have some improvement. One of major problems with current HelpSystem is search/sort algorithm: it just looking on number of matches and this may not correlate with the real article subject. There is an intention to change this for 7.0 (#155111) by providing tags for help topics and ranking them higher. Browser solution looks interesting and questionable as well ;). What do you think about these 2 aspects: 1. Reliable solution to provide content to the browser while user is not on internet. This should not be sensitive to user network/loopback/fw configuration 2. Browser control from IDE. Obvious approach is 'open' and 'forget'. Could this be better ? I learned today that JavaHelp has intermitent severe problems in Solaris: Javahelp bug report https://javahelp.dev.java.net/issues/show_bug.cgi?id=22 NB Related issue (P1, WONTFIX) http://www.netbeans.org/issues/show_bug.cgi?id=127368 The end result is that some solaris users won't be able to open the help window. So maybe an HTML based alternative is a good idea. The IDE has a built-in HTTP server (used for javadoc help) that could probably be used to render JavaHelp HTML. I wonder if using this internal web server could solve the internal-external link problem you're talking about. The problem I have with this idea is getting rid of the help system when NB isn't just an IDE. It is an application framework which an IDE is built atop. Seems a better idea would be to take the sources for JavaHelp, and make a version for NB where patches could be ported to the openjdk after things are made better. Then it can help everyone. If folks need to run other media or do things from their RCP applications help they can use a link to kick off an external browser. Sure, a browser solution which could work like MSDN would be good for NB things at large for folks to browse through, but I don't find that an alternative. It doesn't integrate, and it doesn't look the same. To me that would be another feature. Too, maybe it shouts more that a web component, a real one, is needed for Java, but that is another story unless part of taking JavaHelp and improving it to give back is a sub-project to make a real HTML/browser component that actually follows standards. FireFox is open source after all. JavaHelp bug #22 does not seem to be Solaris-specific. The exceptions report page lists all different OSs. JavaHelp is not part of OpenJDK. It is an independent project. >JavaHelp is not part of OpenJDK. It is an independent project.
Even better :-D Seems that would make it easier to get just a branch of that code, a released branch, add some fixes,
send the patches, and use the patched release in NB. Of course I guess some of it can go back to having a better web
component for Java so other things such as Flash etc can be embedded maybe. I don't know, but it seems most of the
things in this umbrella could be fixed right in JavaHelp without a full blown rewrite, and if someone needs, a port of
Firefox/Gecko to Java could be a hole other thing in and of itself for a better future of working with HTML in Java. Not
saying that will be a cake walk, just saying it is a workable path.
Moving JH issues to Victor. |