Skip to content

The AppImage release says “'qtdomterm' missing” or showing an empty Electron window #122

@matj1

Description

@matj1

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.

Activity

PerBothner

PerBothner commented on Jan 16, 2024

@PerBothner
Owner

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

matj1 commented on Jan 18, 2024

@matj1
Author

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

matj1

matj1 commented on Jan 18, 2024

@matj1
Author

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

PerBothner commented on Jan 18, 2024

@PerBothner
Owner

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

matj1 commented on Jan 18, 2024

@matj1
Author

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

PerBothner commented on Jan 19, 2024

@PerBothner
Owner

I suggest that DomTerm would look also for chromium, among them, so the link would not be needed.

Done (in git master).

PerBothner

PerBothner commented on Jan 20, 2024

@PerBothner
Owner

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

matj1 commented on Jan 20, 2024

@matj1
Author

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
PerBothner

PerBothner commented on Jan 20, 2024

@PerBothner
Owner

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

matj1

matj1 commented on Jan 20, 2024

@matj1
Author

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

PerBothner commented on Jan 20, 2024

@PerBothner
Owner
PerBothner

PerBothner commented on Jan 21, 2024

@PerBothner
Owner

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
matj1

matj1 commented on Jan 24, 2024

@matj1
Author

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

PerBothner commented on Jan 24, 2024

@PerBothner
Owner

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.

PerBothner

PerBothner commented on Jan 25, 2024

@PerBothner
Owner

I made a 3.2.0 release.

matj1

matj1 commented on Jan 25, 2024

@matj1
Author

Everything here seems alright, so I close this.

PerBothner

PerBothner commented on Jan 25, 2024

@PerBothner
Owner

Thanks for working with me on this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @PerBothner@matj1

        Issue actions

          The AppImage release says “'qtdomterm' missing” or showing an empty Electron window · Issue #122 · PerBothner/DomTerm