Multiple windows with electron slightly buggy about domterm HOT 12 CLOSED

Hm. I don't notice that "newly opened windows take longer to load than the initial one". It is possible this may be fixed now.

I checked in a fix for that they "don't respect the window.geometry setting anymore" .

There is still an inconsistency: An explicit --geometry option on the initial domterm command becomes the default for future windows, but a --geometry on subsequent commands only affects the current command. Perhaps there should be a --default-geometry option in addition to the --geometry option. That leads to the open question which "wins" when the settings.ini is updated but there is a --default-geometry set.

from domterm.

I've just checked out the master branch, and it sadly doesn't appear to be fixed yet.
Here's a gif showcasing what i'm seeing right now (sorry for the terrible quality, had to keep the filesize small)

As you can see, the second window i open ignores the geometry from the settings.ini (it does work when i set the --geometry option in the command), and takes significantly more time till it's ready to be used.
(It also showcases another bug where i get a bunch of characters on opening the second window but i'm not entirely sure yet if that's just my weird .zshrc haha)

Electron version is 2.0.2, not sure if important but i forgot to add that last time

from domterm.

"Electron version is 2.0.2" turns out to be important. I was going have you try some other things, but I downloaded 2.0.2 and I also saw a big slow-down on start-up. I also see some warnings when I open the debugger window. See https://electronjs.org/docs/tutorial/security#electron-security-warnings . I don't know if the warnings explain the slowdown; I'll work on fixing the warnings and see.

However, setting window.geometry=W*H in settings.ini does work for me (i.e. for subsequent windows as well), so that may be a different problem.

from domterm.

Ah, good to know, sorry for forgetting the electron version in my initial report 😅

And regarding the window.geometry: I'm not sure what i'm doing wrong, I've set window.geometry = 100x800, and the first window always accepts these values, the second one never does. I've tried various combinations now, and none seem to change that.

from domterm.

I figured out how to avoid the warnings (in the console), but that didn't fix the start-up delay.
The delay seems to be specific to Electron - I don't see it using a browser, or the --qt front-end, or the --chrome-app front-end (basically Google Chrome in an uncluttered "app" window).
Presumably somebody is waiting for something and then finally times out - but figuring out may be difficult ...
I don't know which OS you're running (it was hard to tell from your screencast), but you could try the Qt front-end - they should be easy to install on Fedora or Ubuntu at least.
The --chrome-app fornt-end isn't bad, but is missing menus (menubar and context menu - I'm evaluating how to implement those in portable JavaScript) and --geometry doesn't work (that seems hard to fix due to Chrome limitations).

from domterm.

I filed an Electron issue: electron/electron#13163
There is a possible work-around - see the if (false && DomTerm.isElectron()) code (and the comment before it) in DomTerm.openNewWindow in hlib/terminal.js. However, that has some timing problems of its own that I have not figured out.

from domterm.

I don't have a good fix for the Electron front-end yet, but would you mind trying out the --chrome-app front-end instead and let me know what you think? I.e.

$ domterm --chrome-app

This option starts a Chrome windows in "app" mode. I.e. as a bare window. No browser menus. Instead, I implemented a menubar and context (right-click) menu using the nwjs-menu-browser library. This is almost as nice as the Electron front-end, without the overhead and problems of Electron. I'm thinking of making this the preferred front-end for DomTerm.

The menubar and context-menu also works in a "normal" desktop browser - I've tested Firefox and Chrome.

from domterm.

I'm liking the chrome-app front-end a lot, honestly. It's a great alternative to electron, especially with the custom context menu.

Funnily enough, now the electron front-end is quite buggy haha. When i try to open a second window, it returns with error code 255, and the websocket connection of the first window closes.

from domterm.

Correction: That doesn't seem to happen only on the electron front-end, it also happens when i e.g. open a session in chrome and then open another one in chrome-app, then the chrome-app won't open and the websocket connection in chrome dies.

from domterm.

I fixed two small bugs that may help. I'm also trying to understand why sometimes opening a window hangs - it doesn't appear to Electron-specific but might be a bug in the (C-based) server code. It's hard to pin down - perhaps some kind of race condition occasionally causing a deadlock.

from domterm.

I fixed it so opening a new terminal using the menu or the keyboard shortcut (ctrl-shift-N) requests a new BrowserWindow from the existing Electron application. This avoids the multi-second delay. (Also, for non-Electron, a new window is opened using JavaScript window.open, rather than via the server.)

Opening a new window via the command-line (e.g domterm new) still causes the delay; the fix for that is for the server to forward the new-window request too an existing Electron window. That is not yet implemented - it requires the server to keep track of which windows are Electron windows.

Finally, there is still a problem that opening too many windows can cause to new window to wait indefinitely, until an existing window is closed. This may be an http server problem - I've reported one bug that may be relevant.

from domterm.

It seems to work ok now.
The above-mentioned problem "opening too many windows can cause to new window to wait indefinitely" was tricky - see the "problems with big dynamic content" thread on the libwebsoclets mailing list. Fix that allowed us to create new Electron windows in the same Electron application, which fixed the delay.

from domterm.