On 2016-10-21 08:04, Lars via Lazarus wrote: > powerful like a full fledged .CHM system or .hlp system. But even chm and > .hlp files are primitive, they are just basic, and 1990's technology.
One thing you are overlooking is that most help authors don't use any of the advanced features of the existing help systems. For example: OS/2 INF/HLP help system has by default 2-way communication support. This is an excellent way to incorporate step-by-step tutorial help. In all my years of using OS/2, I've *never* seen anybody use that feature - except IBM. IBM did it very well, in where the help window tells the use what to do, a overlay appeared over the application window highlighting what the help is referring too. The user does what was instructed, and the help window automatically updates to the next step so so forth. Brilliantly useful, but nobody used it. > With chromium embedded it seems you can literally do anything you want: The down side being you need to have a 80-250MB application (full Firefox or Chrome or Chromium browsers and all dependencies) installed just to view some help contents. Also what happens if you don't use Firefox or Chrome? Also starting up those web browsers, even in an embedded environment is a slow process and they are huge and memory hungly! A decade ago I researched all of these things for a client of mine. We wanted offline help, must be searchable, help must load instantly (even a 1 second loading time is too slow), the help contents must be easy to author and no large supporting libraries/runtimes etc. My client also wanted context sensitive help down to the widget on a form level. It is atrocious that applications don't supply good offline help (if any help is even supplied) these days. It was surprisingly hard to find a solution, especially something cross-platform. In the end I researched help formats with the goal to implement our own help viewer. We looked at Microsoft's HLP, CHM formats, IBM's INF, OpenOffice's help, Gnome's help sytem and a few others. Long story short, in the end we decided on the IBM created INF help format, and I implemented a cross-platform help viewer that ticks all the requirements listed above and more. fpGUI's DocView help viewer was born. A 1MB help viewer that can load and parse not just one, but multiple INF files, and display the requested help topic in under a second. If multiple INF files were loaded their TOC get merged into a single TOC treeview. If they supply Index details, those too get get merged into a single Index view, or a Index can be auto-generated at runtime. It has advanced search features, hyperlink support, the usual rich text display features, bookmark support, user defined inline annotation support and DocView includes its own help file describing all its features (help on help). The INF help file format is impressively efficient in speed and size (help topic contents are indexed lookups to a global word dictionary - reducing size, allows for full-text searching etc). The INF help compiler I use is a cross-platform open source implementation from the OpenWatcom Compiler project. A single small executable with no external dependencies. FPC's fpdoc also supports generating IPF output which can then be compiled into binary INF help files. DocView can also be integrated with LCL or fpGUI application. If you log into the Lazarus Forum and view the following link, there is an attached source code of a LCL application, showing exactly how to integrate DocView with LCL applications to give you context sensitive help. http://forum.lazarus.freepascal.org/index.php/topic,27864.msg173887.html#msg173887 It can also be integrated into Lazarus IDE, Delphi IDE or any programmer editor that supports "external tools" functionality - without needing to compile and install IDE add-ons, yet still gives context sensitive help per keyword. http://fpgui.sourceforge.net/docview_ide_integration.shtml > they are static html files without any power added > to them, or they are chm files which are simple but not so powerful. What I also don't want from a help file is a Telly Tubbies like looking help text. By that I mean, some idiot with no flare for typography and design, being allowed to author and "customise" help content to death - making my eyes bleed just looking at it. And yes, I've seem many such CHM help files. That's why I like more minimalist help text (think OSX). It gets the point (help) across without making my eyes bleed, and no ugly distractions. DocView does allows for some end-user customisation though - changing the proportional and mono fonts used, font size, page background color and search highlighting color. The help content author doesn't need to stress about those "customisations" as it is not up to them to force their (possibly ugly) design onto the end user. The idea of help text is to help the end-user as efficiently as possible. It is not an excused for the help author to say "oh, look what I can do with colors, fonts and terrible design skills". As far as I'm concerned HTML is not a good choice for a help format. It's way to verbose and gives too much "design power" to the help author - without allowing end-user customisation. Adding JavaScript and such to the mix will make the problem even worse. Also, not all HTML viewer components are created equals. Just compare LHelp output so say kCHMViewer or Firefox. > to the mailing list as an idea for anyone who wants to make a rich help > system with a rich integrated help system. And I posted my personal opinions, which I know others might not agree with - but there you go. ;-) Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus-ide.org/listinfo/lazarus
