From mboxrd@z Thu Jan 1 00:00:00 1970 From: Per Bothner Subject: Re: Any interest in using HTML for locally-installed Texinfo documentation? Date: Tue, 2 Apr 2019 09:46:05 -0700 Message-ID: <256d60e8-0148-1dd3-4c9d-86e14b42060b@bothner.com> References: <87a7h8u4r4.fsf@gnu.org> <20190402150245.GA30067@darkstar> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20190402150245.GA30067@darkstar> Content-Language: en-US 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: Gavin Smith , =?UTF-8?Q?Ludovic_Court=c3=a8s?= , guix-devel@gnu.org, Texinfo List-Id: guix-devel.gnu.org 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 > rendering. 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 > restrictions. 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: https://github.com/PerBothner/DomTerm/tree/master/qtdomterm 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 per@bothner.com http://per.bothner.com/