You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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).
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.
./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:
#122 (comment)
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:
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:
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.
Activity
PerBothner commentedon Jan 16, 2024
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
.matj1 commentedon Jan 18, 2024
./DomTerm.AppImage --webview
seems to do absolutely nothing (with exit code 0). I installed Chromium and created a linkchrome
to it, and./DomTerm.AppImage --chrome-app
seems to work fine.matj1 commentedon Jan 18, 2024
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.PerBothner commentedon Jan 18, 2024
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.
matj1 commentedon Jan 18, 2024
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).
PerBothner commentedon Jan 19, 2024
Done (in git master).
PerBothner commentedon Jan 20, 2024
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.
matj1 commentedon Jan 20, 2024
It says this:
And after installing libwebsockets:
PerBothner commentedon Jan 20, 2024
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 runningdt-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.)matj1 commentedon Jan 20, 2024
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.
PerBothner commentedon Jan 20, 2024
PerBothner commentedon Jan 21, 2024
I uploaded a new DomTerm.AppImage (also to
https://per.bothner.com/tmp/DomTerm.AppImage
) withlibwebsockets
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 finddt-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, butdomterm -Bfirefox -d 15
ordomterm -Bchrome-app -d 15
works, try those and look at the log file (/tmp/domterm-PID.log
). Search fordomterm.jar
. You should see something like: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:matj1 commentedon Jan 24, 2024
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.PerBothner commentedon Jan 24, 2024
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.PerBothner commentedon Jan 25, 2024
I made a 3.2.0 release.
matj1 commentedon Jan 25, 2024
Everything here seems alright, so I close this.
PerBothner commentedon Jan 25, 2024
Thanks for working with me on this.