Edex-ui: Edex-UI does not launch after running the command 'npm start'

[NiramayVaidya]

After running npm start on the terminal, post multiple Gtk WARNINGS, settings are successfully loaded but nothing happens after that. The program doesn't stop either.

[GitSquared]

What version of GTK and/or KDE do you have on this system?

[NiramayVaidya]

My system has GTK version 3.18.9 and KDE 16.04.

[shinenelson]

I've had the same issue on a GNOME system as well. I don't think GTK / Desktop Environment (DE) is related.

However, unlike in the ISSUE-TEMPLATE, though I'm running from the latest master revision ( as of writing ), the version I'm running is v2.2.3-pre. ( Is that an issue with the ISSUE-TEMPLATE, maybe? ).
I guess the OP should have also changed the option to latest since the version in the screenshot doesn't have the -pre suffix and is indeed the latest release.

[GitSquared]

@shinenelson The version on the master branch is the one that's out of sync; I should bump it to v3.0.0-pre since there are some breaking features coming in the next version.

Indeed, thanks for pointing out that OP's version is v2.2.2.

I'm not entirely sure but I believe this bug is caused by a non-compatibility between the bundled Electron version and the GTK version of the system. It will probably be fixed with an update of Electron, something I'm working on merging on master.

[GitSquared]

Electron was updated in 787cb3b - this should now be fixed on master.

[shinenelson]

Unfortunately, the latest master still doesn't resolve the issue for me.

What's even more annoying is that the process captures the Ctrl + C modifier even before the UI is initialized, so the only way to exit the process is to close the terminal session.

[GitSquared]

@shinenelson It captures the keyboard input, so you do see a window appear, right?

Could you forward me your logs from the terminal please

[shinenelson]

Do you mean the edex-ui window? No, it doesn't come up. If it did, I could safely assume that it was something on my end.
Yes, the keyboard capture happens, but the window doesn't appear. I tried looking at the system logs to see if there was anything there, but there wasn't.

I don't understand what logs other than the npm logs you're expecting but here's a screenshot of my entire workspace trying to run the application and frantically trying to quit the process as well.

[GitSquared]

That is... weird. It should always react to interrupt sequences. Looks like it hangs in the middle of the startup process.

Here's a full runtime log of a working version (for comparison's sake):

Yours hangs somewhere between "settings loaded" and "creating terminal process", here's the related code:
https://github.com/GitSquared/edex-ui/blob/88f5eeddd05860caec179071a4bd43e6c327f5a3/src/_boot.js#L185-L200

So sindresorhus/shell-env is probably the one hanging the whole process.
It's a little helper script that runs one command in your shell to print out your env:
[shell] -ilc echo -n "_SHELL_ENV_DELIMITER_"; env; echo -n "_SHELL_ENV_DELIMITER_"; exit

Could you tell me what's in the shell field of ~/.config/eDEX-UI/settings.json? My guess is whatever shell was detected doesn't support the arguments and/or syntax thrown at it by shell-env, which would be the root cause of this issue.

[GitSquared]

And yeah, you were right to point out earlier that it wasn't related to the GTK warnings in OP's logs. Seems like I didn't understand this correctly, sorry about that.

[shinenelson]

Aha, it makes some sense now. Coincidentally, I too was looking at _boot.js yesterday trying to figure what was happening ( though I had no clue how the code actually worked ).

Now that you've isolated the problem to the shell-env package. I think that's exactly where you have the issue since there's the await command there too.

I did some quick tests with whatever I had available readily.

1. I checked the command that shell-env runs on invocation. The command does run successfully ( with the shell variable in the settings file as well as the one that I was trying to invoke the eDEX-UI from ).
   However, something during the shell initialization on both my shells strips out the initial echo -n "_SHELL_ENV_DELIMITER_" command. The end delimiter is echoed properly, but I couldn't find the first one; but my env is being printed out fine.
   I'm not sure whether there's something else hindering the shell initialization. I'll have to dig deep into my shell initialization process ( since I've hacked it extensively over the years to suit my taste ).
2. I noticed that the shell-env package is not listed as a dependency for the project. I couldn't find it in my node_modules directory either. Was it accidentally missed out? I haven't tested installing the package manually yet.
3. There is a catch-throw statement that the command should've caught and thrown an exception, no?

I'm going to do some more extensive tests later :

1. log debugging on the code ( mentioned above; to confirm that it is indeed the await command that is hanging up though I'm almost certain that it is )
2. install the shell-env package manually into the project and see if that resolves the issue.
3. use the -x ( settrace ) flag in the shell command that is run by shell-env to figure whether the issue is on my end with the shell initialization process.

Let me know if I can be of help in some other way.

PS : You can consider me in the "_My machine is fully under my control, tell me what you need_" category, unlike the OP.

[GitSquared]

I noticed that the shell-env package is not listed as a dependency for the project. I couldn't find it in my node_modules directory either.

eDEX uses a two package.jsons system; which used to be standard practice for electron-builder a few years ago. You should look in src/package.json and src/node_modules.

However, something during the shell initialization on both my shells strips out the initial echo -n "_SHELL_ENV_DELIMITER_" command. The end delimiter is echoed properly, but I couldn't find the first one; but my env is being printed out fine.

shell-env is hardcoded to parse the output of it's env-printing command by looking for what's between the two _SHELL_ENV_DELIMITER_ prints.

I tried running some bits of the shell-env source code step by step in a node shell, with a "good" and a "bad" env output - the "bad" one missing the first delimiter.

> goodEnv.startsWith('_SHELL_ENV_DELIMITER_')
true
> badEnv.startsWith('_SHELL_ENV_DELIMITER_')
false
>
> goodEnv.split('_SHELL_ENV_DELIMITER_')[1].length
1760
> badEnv.split('_SHELL_ENV_DELIMITER_')[1].length
0
> badEnv.split('_SHELL_ENV_DELIMITER_')[1]
''
>
> const stripAnsi = require('strip-ansi')
undefined
> stripAnsi('')
''
>_

Missing one delimiter will cause the shell-env parser to work on an empty string, which stripAnsi handles fine - so the whole for() block in the source code I linked above is ignored and everything should return an empty object {} back to eDEX.

Except I tried adding a line in _boot.js to discard shell-env and work with an empty object as an env base, and it handles it just fine, doesn't hang. I'm not sure what I'm missing.

The command does run successfully ( with the shell variable in the settings file as well as the one that I was trying to invoke the eDEX-UI from ).

Could you tell me which shell these two are exactly?

[GitSquared]

@shinenelson