I’m not aware of any specific plans. Sounds like a few on the thread may have sone interest and some solutions but beyond that I’m not sure anyone has actively been working them beyond what’s been expressed here.
I think at the time I was trying to bring in an old plug-in that made use of it but beyond that I’m not focusing on it at the moment. Others may have more to say on the list. On Thu, Jun 10, 2021 at 8:53 AM Arcturus Bootes <arcturusboot...@gmail.com> wrote: > 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 > documentation. > > In terms of outstanding issues > < > https://issues.apache.org/jira/browse/NETBEANS-5225?jql=project%20%3D%20NETBEANS%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20%22platform%20-%20Help%20System%22%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC > > > 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 <ebre...@gmail.com> 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 <niftin...@gmail.com> > 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 > > ebre...@gmail.com > > > -- Eric Bresie ebre...@gmail.com
