Having not drilled down too much yet and thinking from a system perspective (and hope to get this out to the list for others as well)...
Where in the codebase is/would the help functionality be located? And where does the help content reside (is there a standardize location) So assume there are a few parts to the help capabilities: (1) Ability to display help materials in a user friendly format (2) The help material may be context sensitive help (i.e. when in a given context, bring up (3) Be compatible with existing local documentation (4) Be able to reference to remote documentation (sites) where applicable (5) Potential usage within the IDE and/or IDE modules (6) Potential usage by Netbeans platform applications What formats are presently supported (I.e. javadoc, html, text, markdown, etc.)? And does the existing interface allow alternative help formats like this effectively? So basically swap out the JavaHelp interface with a HelpView/Viewer interface of some Type (maybe something like an HTML Viewer) component here in some way? Eric On Sun, Jul 26, 2020 at 1:29 AM Tim Boudreau <[email protected]> wrote: > Funny, I was recently adding help to an old NetBeans-based image/vector > editor I've been toying with updating, and the idea of using Javadoc simply > made me ill, so I wrote the beginnings of a help system from scratch, where > help is generated in code annotations in Markdown, which an Antlr parser > and some Swing magic render directly to the screen without ever translating > to HTML. It's a work in progress, as I have another project I'm trying to > wrap up. > > Many years ago, when Sun open sourced it, I had the joy of converting the > code to Ant and making it open-source-friendly. It was old, > long-in-the-tooth and rather vile then - at best, it's an ugly (the classic > Swing "border buildup" issues) clone of 1990's era Windows Help. It is > long past time for it to die. It's one of those things nobody actually > likes, but nobody actually wants to write a replacement for either. > > I imagine it wouldn't be that hard to write something that can consume the > existing input files, but something simple, modern and that either uses the > user's web browser, or at any rate doesn't demand in-application HTML > rendering, and doesn't require HTML as its markup, would be a good idea. > > -Tim > -- Eric Bresie [email protected]
