[Lazarus] Help System with Chromium Embedded component

[Graeme Geldenhuys]

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