Getting DomTerm working on Mint (and probably Ubuntu 18.04LTS as well)

[mcarans]

qtdomterm /usr/local/bin/fish gives a blank white screen with no prompt.

domterm --chrome /usr/local/bin/fish works.

Also is the qt frontend the best frontend for Linux or is it better to use the electron one (which I've not tried yet)?

[PerBothner]

"domterm --chrome works."

That at least is something. You can try domterm --chrome-app instead: It opens a fresh window without the browser clutter. It is almost as nice as the Electron or Qt version, though there are some permission-related annoyances, such as the Edit/Paste and Edit/Copy menu item don't work, though the keyboard shortcuts do. (You should start a Chrome browser first, even though --chrome-app creates a fresh window.) (The Edit/Paste and Edit/Copy menu item problem can be worked around by having the domterm server call some external programs, but there are some problems with that so I haven't yet done it.)

"Also is the qt frontend the best frontend for Linux or is it better to use the electron one (which I've not tried yet)?"

The Electron and Qt front-ends are very similar. I recently fixed most of the Electron-specific or Qt-specific annoyances.

The best one is whichever one you can get to work with the least amount of pain!

When you try Qt (or Electron) again, make sure there isn't some existing domterm process in the background. I use ps aux|grep domterm. Likewise for electron processes, if you used the electron version.

If you just get a blank screen, you could try opening a debugger window. You need to start qtdomterm with (say) --remote-debugging-port=2222 and open localhost:2222 in a Chrome (non-Firefox) browser. Check to see what error messages have been printed to the JavaScript console.

It is possibly you have a non-working/incompatible version of Qt. I've only tested DomTerm on Fedora and WSL (Ubuntu under Windows), though the latter not recently.

The domterm status command is useful to get version numbers and more.

[mcarans]

Using the debugging port I see in the console:
Uncaught TypeError: DomTerm.makeElement is not a function
at loadHandler (domterm-client.js:367)
http://localhost:44401/favicon.ico Failed to load resource: the server responded with a status of 404 (Not Found)

qtdomterm status gives:
DomTerm version 2.0.0 (git describe: 1.0-496-g4bf07c7)
Copyright 2019 Per Bothner and others
Using Libwebsockets 3.2.99
Reading settings from: /home/mcarans/.config/domterm/settings.ini
(no domterm sessions or server)

I built libwebsockets from head GitHub.

qmake --version
QMake version 3.1
Using Qt version 5.9.5 in /usr/lib/x86_64-linux-gnu

settings.ini:
command.electron=/home/mcarans/Applications/electron/electron
shell.default = /usr/local/bin/fish
style.dark = on

[PerBothner]

I'm seeing:

$ qmake-qt5 --version
QMake version 3.1
Using Qt version 5.12.5 in /usr/lib64

After starting qtdomterm, domterm status reports:

DomTerm version 2.0.0 (git describe: 1.0-496-g4bf07c7-dirty)
Copyright 2019 Per Bothner and others
Using Libwebsockets 3.2.99
Reading settings from: /home/bothner/.config/domterm/settings.ini
Backend command socket: /run/user/1000/domterm/default.socket
session#: 1, pid: 187796, tty: /dev/pts/2
  window: qtwebengine: 5.6.1, chrome: 45.0.2454.101

It's plausible it's a difference between Qt 5.9 and 5.12, specifically the version of Chrome that the respective QtWebEngine is based on. It's difficult for me to test let alone support older versions of dependencies (especially on platforms I don't have easy access to). If you're curious, you can git checkout an older version of DomTerm; that might work on Qt 5.9, but it hardly seems worth it, since I can't provide much help with older versions.

Downloading and using Electron based on the instructions is simple, so I'd try that. Or settle for the limitations of domterm --chrome-app.

[mcarans]

I managed to get it to work by doing the following:
Remove the default QT 5.9:
sudo apt remove qt5-qmake qt5-default libqt5webengine5 libqt5webchannel5-dev qtwebengine5-dev

Add a PPA containing newer QT:
sudo add-apt-repository ppa:beineri/opt-qt-5.12.6-bionic
sudo apt update
Install QT:
sudo apt install qt512-meta-minimal
sudo apt install qt512webengine qt512webchannel qt512tools

Also, I found a missing symbolic link during compilation:
sudo ln -s /usr/lib/x86_64-linux-gnu/libGL.so.1 /usr/lib/x86_64-linux-gnu/libGL.so

[PerBothner]

Let me know how well things work for you, and if there is anything annoying.

Next there is question about whether or how to change the build instructions - since it may be awfully specific to a particular version of Qt and Mint. At the very least I should note that Qt 5.9 doesn't work.

First, though, I should try to build DomTerm on WSL (with and without Qt) - which also be useful for Ubuntu.

[lypanov]

Same issue here on WSL with Qt 5.9 the default on Ubuntu 18.04.

To get this qt512 ppa working I also had to first source /opt/qt512/bin/qt512-env.sh to get the correct environment variables to allow ./configure / make to work correctly.

Also note that to get the above Qt5 working you need to perform magic library stripping incantations described here: https://superuser.com/questions/1347723/arch-on-wsl-libqt5core-so-5-not-found-despite-being-installed

Looking now into how to get hyperlinks clickable within this environment.

[PerBothner]

Recently I've tried to get DomTerm working using the JavaFX WebView component (for use by Java application). That too had a weird problem with DomTerm.makeElement not being found. That seems to have changed into a different problem in my very latest code - with TextEncoder not being found. Interesting and strange.

[PerBothner]

Some interesting data points:

The default build works with JavaFX 13 (AppleWebKit 608.1), but doesn't work with JavaFX 8 (AppleWebKit 602.1), which gets the missing DomTerm.makeElement error.

However, JavaFX 8 (AppleWebKit 602.1) does work if configuring --with-closure-compiler (using changes I checked in just now). This uses the Closure transpiler/minifier. I tried using the Fedora package; presumably it should work just as well on Ubuntu (apt-get closure-compiler), though I haven't tried that.

Presumably, the code is using some ES6-ism which older browsers get confused by, but Closure "transpiles" it to es5 constructs that are handled. If it is something minor, it might be worth changing, but in general I prefer to make use of modern JavaScript, especially if a transpiler like Closure works for older browsers.