From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gavin Smith Subject: Re: Any interest in using HTML for locally-installed Texinfo documentation? Date: Tue, 15 Oct 2019 20:27:19 +0100 Message-ID: References: <87a7h8u4r4.fsf@gnu.org> <20190402150245.GA30067@darkstar> <256d60e8-0148-1dd3-4c9d-86e14b42060b@bothner.com> <20190407162804.GA28500@darkstar.example.net> <87k1g4v8dq.fsf@gnu.org> <20190413162121.GA28137@darkstar.example.net> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: <20190413162121.GA28137@darkstar.example.net> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-texinfo-bounces+gnu-bug-texinfo2=m.gmane.org@gnu.org Sender: "bug-texinfo" To: =?UTF-8?Q?Ludovic_Court=C3=A8s?= Cc: guix-devel@gnu.org, Texinfo List-Id: guix-devel.gnu.org 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 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.