netbeans-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arcturus Bootes <>
Subject Re: Status of JavaHelp
Date Thu, 10 Jun 2021 13:52:25 GMT
Hi Eric,

It's been some time you had a response to the questions you raised here. I
noticed that with 12.4 the link to help now just opens the online

In terms of outstanding issues
regarding this topic I didn't see anything specifically mentioning the plan
going forward. Do you know if there are any documented plans for the future
of built in help?

If the answer is that NetBeans is no longer looking to include built-in
help and you have to use the online docs then that's alright; just keen to
know where NetBeans stands on the matter.

Regarding an RPC NetBeans platform application I'm working on (since NB 7
and now using NB 12.0), I wanted to ideally keep in step with what NetBeans
is doing so I wanted to plan a way forward that would be compatible with
what NetBeans does ideally.

Presently I am still adding the jhall jar and modified
org-netbeans-modules-javahelp.jar back in to retain the built in help
system. However I am now exploring options.

Thank you.

On Mon, 27 Jul 2020 at 01:18, Eric Bresie <> wrote:

> 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 <> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message