Re: Any interest in using HTML for locally-installed Texinfo documentation?

[Per Bothner <per@bothner.com>]

On 4/2/19 8:02 AM, Gavin Smith wrote:
> Using JavaScript within a web browser has big drawbacks due to its
> "sandboxed" nature.  (You can't access environment variables, for
> example.)  However, we'd want to avoid having to re-implement too much
> of the web browser; for example, input file parsing, text layout and font
> rendering.
Both Electron and QtWebEngine have mechanisms for communicating between
the "browser" window and the main application, which is not sandboxed.
(For QtWebEngine the main application is regular non-sandboxed C++ code.)
For a desktop browser like Firefox, one could pass important environment
variables in the URL.  For bi-directional communication between a
sandboxed desktop browser and the C/C++ wrapper program one can always
use WebSockets or XmlHttpRequest ("AJAX").

Note below I'm talking in terms of an ideal long-term roadmap.
Medium-term one would prioritize, of course.

I'm assuming you would prefer to not require either Qt or Electron as
a dependency.  In that case my recommendation is two separate commands,
supplied by two separate distribution packages:

(1) A plain 'info' command can parse command-lines, find the right
html file, and then either open a window in the default desktop browser,
or display the file using 'emacs -nw'.  (If old-style info files are
available, it could also display those directly.) If qtinfo or electroninfo are
installed, they could be used to open a window instead.

Cross-manual links and some other functionality may be restricted when
using a standard desktop browser.

(2) Either 'qtinfo' or 'electroninfo' or both, which is an alternative
or wrapper for info using QtWebEngine or Electron, respectively.
GtkWebView may also be worth considering, but I have no experience with it.

> This doesn't address the issue of multiple installed versions of the
> same manual or manuals in different "prefix hierarchies".  I imagine the
> Info browser would interpret the "../" string specially in a link and
> go looking through a search path for the referenced manual.  Again, this
> may be difficult to implement in standard web browsers due to security
> restrictions.

It can be done in a standard web browsers using WebSockets or
XmlHttpRequest (AJAX), but that's more work.

> I'm getting the feeling that we need a web browser, or something like 
> it, which can integrate with the operating system a lot more, without
> sandboxing or security restrictions.

I (tentatively) recommend using QtWebEngine (i.e. 'qtinfo').  Electron is easier
to write and less verbose, but it is heavy duty and packaging may be a pain.
(Though there are other good reasons to package Electron.)  Qt is more
established in the GNU/Linux environment, and is easier to integrate
with C/C++ code, including re-using code from existing info.
A Gtk equivalent would have similar benefits.

If curious, you can look at the Qt code for DomTerm at:
https://github.com/PerBothner/DomTerm/tree/master/qtdomterm
This handles creating a QtWebEngine window, menus, and bi-directional
communication with the JavaScript in the QtWebEngine window.  It's not
super-compact, but it's quite reasonable. (The main C code for
process/pty management is in the lws-term directory.)
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/