unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Gavin Smith <gavinsmith0123@gmail.com>
To: Per Bothner <per@bothner.com>
Cc: guix-devel@gnu.org, Texinfo <bug-texinfo@gnu.org>
Subject: Re: Any interest in using HTML for locally-installed Texinfo documentation?
Date: Sun, 7 Apr 2019 17:28:04 +0100	[thread overview]
Message-ID: <20190407162804.GA28500@darkstar.example.net> (raw)
In-Reply-To: <256d60e8-0148-1dd3-4c9d-86e14b42060b@bothner.com>

On Tue, Apr 02, 2019 at 09:46:05AM -0700, Per Bothner wrote:
> 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").

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

To build this, qmake must be installed.  It can be built by opening 
docbrowser.pro with qtcreator.  Running qmake would probably also work:
I have a Makefile inside the build directory build-docbrowser-Desktop-Debug/
(inside the js/ directory, at the same level as docbrowser/) with a 
comment:

#############################################################################
# Makefile for building: docbrowser
# Generated by qmake (3.1) (Qt 5.9.6)
# Project:  ../docbrowser/docbrowser.pro
# Template: app
# Command: /usr/bin/qmake-qt5 -o Makefile ../docbrowser/docbrowser.pro -spec linux-g++ CONFIG+=debug CONFIG+=qml_debug
#############################################################################



It's at a very early stage of development, but shows how bidirectional
communication with info.js can work.  This uses QWebChannel for bi-directional
communication: I believe domterm uses libwebsockets which is not specific to
Qt.

The QTINFO_DATADIR environment variable must be set to the "js" directory of
the sources.  The program can find manuals under the "examples" subdirectory.

The index search doesn't work because of this bug:

https://bugreports.qt.io/browse/QTBUG-54433

The drop-down list for indices would have to be implemented on the C++ 
side.

I don't know how far I am going to push this, but should do a bit more 
on it in the next few days.  (Development is slow for me because I am not very
familiar with Qt, C++, or JavaScript.)  The next things for me to work on are
proper handling of inter-manual links, as well as injecting info.js into the
HTML pages (instead of requiring it to be referenced in the HTML files in a
<script> tag).

> 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.

This can be considered if a desktop browser is ever finished.

> > 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.

The current state of the work intercepts links to external manuals (but 
doesn't do much with them yet).

> 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.)

I never got this to work, but it was useful to be able to look at the source
code.

  reply	other threads:[~2019-04-08  9:38 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-01 12:55 Any interest in using HTML for locally-installed Texinfo documentation? Gavin Smith
2019-04-01 14:01 ` sirgazil
2019-04-02  9:37 ` Ludovic Courtès
2019-04-02 15:02   ` Gavin Smith
2019-04-02 16:46     ` Per Bothner
2019-04-07 16:28       ` Gavin Smith [this message]
2019-04-08 15:12         ` Ludovic Courtès
2019-04-08 15:39           ` Pierre Neidhardt
2019-04-08 23:46           ` Gavin Smith
2019-04-09  6:25             ` Eli Zaretskii
2019-04-13 16:21           ` Gavin Smith
2019-04-14 19:25             ` Pronaip
2019-10-15 19:27             ` Gavin Smith
2019-10-15 20:20               ` P
2019-10-15 20:35                 ` Gavin Smith
2019-10-15 20:40                 ` Per Bothner
2019-10-15 21:00                   ` Gavin Smith
2019-10-15 21:09                     ` Per Bothner
2019-10-15 21:30                       ` Gavin Smith
2019-10-16  1:39               ` Ricardo Wurmus
2019-10-19 20:31               ` Ludovic Courtès
2019-10-22 19:00                 ` Gavin Smith
2019-10-22 20:18                   ` Gavin Smith
2019-11-03 14:04                   ` Ludovic Courtès
2019-11-03 15:37                     ` Gavin Smith
2019-11-06 21:49                       ` Ludovic Courtès
2019-04-03 21:21     ` Ludovic Courtès
2019-04-04 10:33       ` Gavin Smith
2019-04-02 15:31   ` Per Bothner
2019-04-03 21:11     ` Ludovic Courtès
2019-04-03 22:44       ` Per Bothner
2019-04-04 10:23       ` Gavin Smith
2019-04-04 16:02         ` Ludovic Courtès
2019-04-02 20:12   ` Ricardo Wurmus
2019-04-02 20:27     ` Ricardo Wurmus
2019-04-02 22:58       ` sirgazil
2019-04-02 22:10     ` Per Bothner
2019-04-02 23:09       ` sirgazil
2019-04-03  8:43         ` Gavin Smith
2019-04-03 14:23           ` sirgazil
2019-04-03 14:40             ` Per Bothner
2019-04-03 14:49       ` Ricardo Wurmus
2019-04-02 21:02 ` George Clemmer
2019-04-07 11:08   ` Gavin Smith

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190407162804.GA28500@darkstar.example.net \
    --to=gavinsmith0123@gmail.com \
    --cc=bug-texinfo@gnu.org \
    --cc=guix-devel@gnu.org \
    --cc=per@bothner.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).