DomTerm
DomTerm copied to clipboard
PerBothner
The AppImage release says “'qtdomterm' missing” or showing an empty Electron window
I have the AppImage release of DomTerm 2.9.4. When I try to make a new window, it always replies 'qtdomterm' missing with exit code 1 or shows an empty Electron window.
If I run ./DomTerm.AppImage --electron, it switches to showing an empty electron window, and, if I run ./DomTerm.AppImage --qt, it switches to replying 'qtdomterm' missing.
What is wrong here? The documentation says that the release includes the qt frontend.
The Qt front-end is dynamically linked with Qt libraries that you might not have installed. Or you might have an incompatible version of the libraries. It might be possible to use static linking for qtdomterm - but that has some complications plus it would make the AppImage much bigger.
The empty Electron window is strange.
I'll see if I can make a new AppImage that I hope will work better. Until then, you I suggest try --webview or --chrome-app.
./DomTerm.AppImage --webview seems to do absolutely nothing (with exit code 0). I installed Chromium and created a link chrome to it, and ./DomTerm.AppImage --chrome-app seems to work fine.
Without the link, it said neither chrome or google-chrome command found.
I suggest that DomTerm would look also for chromium, among them, so the link would not be needed.
The AppImage is really old. I'm hoping to create a newer one, but I got distracked by trying to update the wry front-end, which I would like to include before I make a new version. (The Wry project is promising, but they're still at the stage of changing APIs - a lot.)
If you comfortable compiling things (the instructions are pretty detailed), you could trying building it directly from a git clone.
I gave up trying to compile DomTerm after several issues (some with the relevant packages on AUR and some with direct compilation) the last of which was this (#121).
I suggest that DomTerm would look also for chromium, among them, so the link would not be needed.
Done (in git master).
Could you try this? https://per.bothner.com/tmp/DomTerm.AppImage
The default front-end is now -Bwry (the -B option is now preferred for selecting a front-end). This is less likely to have issues with incompatible libraries, though does have some downsides compare to the -Bqt or -Belectron versions.
I'm thinking I'l try it out for a few days. If it seems good, I'll update to a new version number and make a release.
It says this:
./DomTerm.AppImage: error while loading shared libraries: libwebsockets.so.19: cannot open shared object file: No such file or directory
And after installing libwebsockets:
cannot find dt-wry command
./DomTerm.AppImage: error while loading shared libraries: libwebsockets.so.19: cannot open shared object file: No such file or directory
Oops. I meant to build the image with libwebsockets statically linked. The makefile rules even has a warning for that. Probably should change that to an error.
The cannot find dt-wry command is mystifying. The same DomTerm.ApeImage works for me and is running dt-wry. Perhaps the way the domterm server searches for the dt-wry command is unreliable - or doesn't work the way you invoke DomTerm.AppImage. (It looks for ../libexec/dt-wry relative to the domterm server executable.)
Should I have something specific installed in a specific directory? I have just the AppImage as ~/bin/domterm and libwebsockets installed from what I consider relevant for this. I didn't install anything specific for wry because I don't know what.
Shouldn't need anything special for wry. You can try invoking the DomTerm.AppImage directly with an absolute path. I'll try your way later, probably this evening.
On January 20, 2024 12:40:34 PM PST, matj1 @.***> wrote:
Should I have something specific installed in a specific directory? I have just the AppImage as ~/bin/domterm and libwebsockets installed from what I consider relevant for this. I didn't install anything specific for wry because I don't know what.
-- Reply to this email directly or view it on GitHub: https://github.com/PerBothner/DomTerm/issues/122#issuecomment-1902260426 You are receiving this because you commented.
Message ID: @.***>
I uploaded a new DomTerm.AppImage (also to https://per.bothner.com/tmp/DomTerm.AppImage) with libwebsockets statically linked.
However, I don't have a fix for not being able to find dt-wry. I wouldn't manage to invoke the appimage and not have it find dt-wry. Could you tell me exactly how you install and run the appimage? Possibly a permission problem? What is your $PATH?
One datapoint: If plain domterm (presumably either renamed from or linked to DomTerm.AppImage) doesn't work, but domterm -Bfirefox -d 15 or domterm -Bchrome-app -d 15 works, try those and look at the log file (/tmp/domterm-PID.log). Search for domterm.jar. You should see something like:
[2024/01/21 08:41:02:9542] I: [2024/01/21 08:41:02:9542] I: [vh|1|default||0]: lws_create_vhost: mounting file:///tmp/.mount_domtertyY65w/usr/share/domterm/domterm.jar to /
If you look /tmp/.mount_domtertyY65w/ (or whatever) that is the mounted appimage, The domterm executable is /tmp/.mount_domtertyY65w/usr/bin/domterm. The dt-wry executable should be /tmp/.mount_domtertyY65w/usr/libexec/dt-wry. You should be able to run that as a very limited browser, for example:
/tmp/.mount_domtertyY65w/usr/libexec/dt-wry https://google.com
Excuse that I reply late. I was not on the PC with the issue for the past 3 days.
The new AppImage works with wry with no issues.
The log says that the JAR file is in /tmp/.mount_domterrRIEgh/…, but that directory does not exist, although there is /tmp/.mount_domterRdD0S9/. So I went there and ran dt-wry http://6502.org, and that worked. I don't know what is up, but it seems not important.
The log says that the JAR file is in /tmp/.mount_domterrRIEgh/…, but that directory does not exist
The directory would only exist while the appimage is running. So you would have to look at the log files before you exit the DomTerm.AppImage "application".
Anyway, cool that it now works for you. Let me know if you have further problems or annoying bugs.
Currently, I'm focusing on xterm.js as an alternative "display engine" for domterm. This has two advantages: It is quite a bit faster (at least certain operations), and there is a community using and developing it. However, xterm.js needs a lot of work (including core data structure changes) before it can support the sort of things DomTerm offers, so it's a slow process.