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: Thu, 4 Apr 2019 11:23:20 +0100 Message-ID: <20190404102320.GA6369@darkstar.lan> References: <87a7h8u4r4.fsf@gnu.org> <87ef6ipzef.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([209.51.188.92]:53983) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hBzU8-0006DL-H8 for guix-devel@gnu.org; Thu, 04 Apr 2019 06:20:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hBzU7-00046J-CZ for guix-devel@gnu.org; Thu, 04 Apr 2019 06:20:40 -0400 Content-Disposition: inline In-Reply-To: <87ef6ipzef.fsf@gnu.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Ludovic =?iso-8859-1?Q?Court=E8s?= Cc: guix-devel@gnu.org, Per Bothner , Texinfo On Wed, Apr 03, 2019 at 11:11:36PM +0200, Ludovic Courtès wrote: > I find things like DOMTerm very impressive, and it’s true that > HTML/JS/CSS nowadays constitute an unequaled UI framework (to the point > that GNOME Shell is also written in JS + CSS.) > > That would be a good argument in favor of doing things this way. Yet, I > have to say that this is not a direction that I like, technically and > otherwise (we’re talking about code bases orders of magnitudes bigger > than all of Texinfo including info-stnd, and code bases under the > control of a couple of companies.) We need something that can render text and has hyperlinks. When the user clicks a hyperlink, the program should have control over what happens. It doesn't sound like a very complicated problem. Maybe there is a lightweight solution that doesn't require embedding a full web browser in the program. For example, in Qt there is the QLabel widget which appears to support links in text: https://doc.qt.io/qt-5/qlabel.html#signals It may be possible to change the embedded web browser to a different one if a company controlling it takes it in a bad direction. Ideally, we'd avoid tying a graphical help browser into large frameworks like Chromium. However, I think that an embedded browser (as in DomTerm) is a good place to start, reusing the existing JavaScript code. Maybe simpler solutions could be explored later. I've been trying to learn about Qt and it certainly is quite complex (taking many hours to compile some of its development tools). > I was mentioning this because it’s an experiment that Andy Wingo did > about 15 years (?!) ago. Andy wrote the Texinfo parser that’s now part > of Guile, and then had a Guile-GTK program that used a tree widget to > show the contents, had clickable links, text would reflow, etc. (See > . > Unfortunately the screenshot has disappeared.) > > That said, it surely is quite a bit of work, but I think it’s an option > we could consider. This is an interesting idea. How far developed was the program? Is it still extant? texi2any has its own Texinfo parser, written in Perl and C.