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: Sat, 13 Apr 2019 17:21:21 +0100 Message-ID: <20190413162121.GA28137@darkstar.example.net> References: <87a7h8u4r4.fsf@gnu.org> <20190402150245.GA30067@darkstar> <256d60e8-0148-1dd3-4c9d-86e14b42060b@bothner.com> <20190407162804.GA28500@darkstar.example.net> <87k1g4v8dq.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Content-Disposition: inline In-Reply-To: <87k1g4v8dq.fsf@gnu.org> 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: Ludovic =?iso-8859-1?Q?Court=E8s?= Cc: guix-devel@gnu.org, Texinfo List-Id: guix-devel.gnu.org On Mon, Apr 08, 2019 at 05:12:17PM +0200, Ludovic Courtès wrote: > > I've started work on a documentation browser using QtWebEngine. The > > work can be seen in the qt-info branch of the Texinfo Git repository: > > > > http://git.savannah.gnu.org/cgit/texinfo.git/tree/js/docbrowser?h=qt-info > > Neat! > > From a “social” viewpoint, I think WebKitGTK would be more appropriate, > GTK+/GNOME being affiliated with GNU. > > Also, QtWebEngine relies on bits of Chromium, which is a real challenge > from a software freedom viewpoint and from a security viewpoint, to the > point that we ended up removing it from our Qt builds in Guix: 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.