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

[Gavin Smith]

Link to thread archive:
https://lists.gnu.org/archive/html/bug-texinfo/2019-04/msg00001.html

On Sat, Apr 13, 2019 at 5:18 PM Gavin Smith <address@hidden> wrote:
> I've moved forward enough with Qt and QtWebEngine that I'm confident
> that it could be used for all the required features: path search for
> manuals and index search.  However, I'm not really happy with the hybrid
> architecture with one part of it in JavaScript, the other part in C++,
> communicating via a web socket.  (The JavaScript part itself
> is in two or three parts that send objects to each other via the "Message API"
> to evade browser security restrictions.)  It's an overly fiddly
> architecture.  I have found there is potential for race conditions to
> exist and also performance problems with JavaScript, especially when
> manipulating the DOM.  The existing JavaScript code is useful as a prototype,
> but I think really the entire thing should be written in one language,
> not two.  Apparently with QtWebKit applications had full access to the
> DOM from the C++ side, but with QtWebEngine you are forced to use
> JavaScript.

I'm replying to give an update on the current situation.

I haven't done any work on this in several months, so I will try to
remember the best I can.

I started another line of development, using the WebKitGTK engine.
http://git.savannah.gnu.org/cgit/texinfo.git/log/?h=webkitgtk-info

WebKitGTK seemed to be the best option for a lightweight embedded
web-browser. I looked into other options, such as the Gecko engine
used inside Thunderbird, but apparently it is not supported any more
to embed it in other programs. WebKitGTK allowed access to the DOM
tree of the documents without the complication of communicating with
embedded JavaScript, as was needed with QtWebEngine.

One annoyance is that there has to be a split architecture where the
DOM access has to be done in a separate process. Apparently this was
different in WebKitGTK version 1, but this was changed. One
recommended way around this is to communicate through dbus. I don't
know if we should depend on dbus, as I think a help system should
minimise dependencies (so you can still get help if your system is
borked). I implemented a Unix socket to pass data, although am not
sure how reliable my code is yet. Another option is to develop based
on WebKitGTK version 1 instead.

I found the documentation worse for GTK+ than for Qt and that it took
longer to get things working. However, compilation speed for C is much
faster, so trying to work things out by trial and error is less
painful. Also, running the program with valgrind showed many issues -
I don't know if this is my code's fault or a general issue with GTK+.
The GTK+ program integrated painlessly with an Automake build system,
whereas Qt code most naturally uses qmake (although qmake is quite
good and it doesn't appear that you are locked into using qmake or Qt
Designer in any way). The layout designer in Qt Designer appears to me
to be superior to Glade for GTK+, but I don't anticipate a need to
have complex widget layouts.

Text search is not implemented, but WebKitGTK does appear to have
special support for this, so it could be supported.

Texinfo 6.7 has been released which marks links to index pages with
the rel="index" attribute. This should make it easier to identify and
load the indices for a manual.

Start up time is an issue. The command-line "info" program starts up
almost instantaneously, whereas starting up a program with WebKitGTK
has a delay of a noticeable fraction of a second - even more so if
there is more than one WebKitGTK instance (for example, to load
indices in the background). I tend to start and stop many "info"
processes freely, rather than keeping the same process running all the
time. There is probably not much that can be done here.

I may be able to get an initial prototype that other people could try
ready in a few days. As ever, if anyone is interested in helping
with/taking over this project, please let me know.