[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Per Bothner
Subject: Re: Any interest in using HTML for locally-installed Texinfo documentation?
Date: Tue, 2 Apr 2019 09:46:05 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

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

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:
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
address@hidden   http://per.bothner.com/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]