Windows Release

[mystchonky]

The build instructions don't work on Windows and manually running the commands (without node scripts) errors out.

Automatic building can be added to the current GH actions workflow.

[smolck]

Hello! Thank you for the issue!

Since veonim did work on windows iiuc, it shouldn't take too much work to get windows builds working again. It's something I've planned to fix but just haven't got around to creating a VM for the purpose. I disabled the GH actions building for windows because of the build errors, as I didn't want those to stop the mac and linux releases.

Would you mind sharing the build error(s) here (and any other info you think is significant) when following the build instructions in the README? That way I might be able to see what exactly the issue is; if not, I can hopefully setup a VM at some point soon to figure out the problem.

[mystchonky]

Hey! Thanks for replying so quickly! I did some tinkering with the code and found few issues:

1. Since Windows handles environment variables differently then Linux/MacOS, the npm script start:release won't work.
2. After discovering this issue, I tried to manually run each script but the .js files were missing in the build directory. Since I am not familiar with TypeScript , it took me a while to realise that I had to compile the files into JS using tsconfig.json. I think this should be added to the build instructions.
3. After this, the build was successful. When launched the app takes a while to launch (nearly 10 secs ) but I am only presented with blank dark grey screen. ( I think it is unable to find the neovim binary although I have the binary in my system-path).

Do let me know if I can provide any logs/other useful info or perform some tests for you.

[smolck]

1. Hmm, I guess I'd need to create a script to check which OS is in use in order to make this work then? What exactly is the difference, i.e. what's the Windows equivalent of NODE_ENV=production electron build/bootstrap/main.js?

2. npm run build is mentioned as needing to be run before npm run start:release, but if you think it should be more specific/detailed then feel free to make a PR. Also, just so you know, tsconfig.json is used solely for type-checking when you run npm run check-types; the actual building is done by Babel via the build script.

3. Could you do npm run start (or I guess the Windows equivalent of node tools/build.js) and paste the devtools console output here? That script will compile & run a development build of uivonim, and open the devtools from the start, which should have the exact error(s) logged. (I need to add this to the README, so if you do create a PR for the previous point feel free to add this info as well.)

[mystchonky]

1. Windows has two different shells (Powershell & cmd) and both have their own ways of handling it (linked). I have tested the cmd method and it worked without any issues (While using both might be necessary , it feels bloated to add both . I will leave that decision to you )

2. Apparently Babel did not build anyfiles (Successfully compiled 0 files with Babel (57ms)) due to this issue. Eliminating the quotes surrounding files extensions from start.js and build.js fixed it . This also fixed the Grey blank Screen issue. I can now reach a proper editing enviroment.

3. At launch console is mainly empty except few WebGL warnings but there is this issue
   

Simple editing and saving works.
Trying to open new buffers results in these errors:
a) At build\neovim\api.js

b) At D:\libDev\git\uivonim\build\services\mru-buffers.js

[smolck]

Thank you for the info! I've pushed 3439db5 which should fix your points 1 and 2, and also 27ae7f2 which should fix 3 (I think that's due to you not setting a colorscheme?); can you re-pull master and see if you still get these issues?

[mystchonky]

Thanks for the quick fixes! Points 1 & 2 have been fixed although tools/start.js also requires that small fix. Issue 3 is almost gone. I only encounter the last error (cannot add to buffer) when testing tabs and buffers.

[mystchonky]

This issue might not be the correct location to discuss this, but what is the project goal about feature parity with Veonim? Will it add onto Veonim GUI features or keep it simple and close to vanilla Neovim as possible ?

[clason]

Well, I wouldn't call neovim (0.5.0+) "vanilla" -- more like "chocolate" or even "Maple Pecan Swirl" ;)

The goal is definitely a "rich" GUI; where the project diverges from Veonim (and Oni etc.) is that instead of implementing IDE features directly or wrapping VS Code extensions, it should leverage as much as possible neovim built-in APIs such as the LSP client or other "core" Lua plugins -- basically a thin coat of chrome on top of the "Lua swirl" of new neovim features.

Ideally, Uivonim will expose a set of basic UI elements (floating windows, prompts, pickers) via a Lua API that plugins like snippets.nvim or telescope.nvim (or their users) can opt-in to replace the corresponding TUI elements.

[smolck]

Thanks for the quick fixes! Points 1 & 2 have been fixed although tools/start.js also requires that small fix.

👍 Will push it when I get the chance.

Issue 3 is almost gone. I only encounter the last error (cannot add to buffer) when testing tabs and buffers.

Everything works as expected though, right? I’m fairly certain that error isn’t windows specific, but another issue. I have yet to really investigate what causes it.

This issue might not be the correct location to discuss this, but what is the project goal about feature parity with Veonim? Will it add onto Veonim GUI features or keep it simple and close to vanilla Neovim as possible ?

As far as feature parity with Veonim goes, there isn’t much of a goal there. Most of the core features of Veonim have been ported (I think), but beyond that this project has different goals (as @clason said) and will likely diverge from Veonim more as time goes on.

For adding GUI features, I’m still not 100% sure where the line is between plugins adding functionality vs. the GUI implementing it, but overall I’d like to add a lot of the eye candy present in stuff like VSCode, so long as it doesn’t bloat/slow down the editor too much. I also plan on leaving most if not all of this stuff opt-in; the editor should be very configurable. I’m open to ideas and thoughts, but I’m not really worried about adding more interesting features not present in the TUI.

Multiple other GUIs have the goal of being as close to vanilla Neovim as possible, but I wouldn’t really say that’s a goal here. Rather, I’m open to experimentation and trying new stuff not possible with the TUI, everything from eye candy to animations.

Thinking about it now though, I would like to make a good enough API that core uivonim would be highly extensible, so that eye candy features could potentially be put in a separate plugin, keeping things lightweight/simple for the default editor.

Anyways, hope that answers your question! Let me know if you have any more!

[smolck]

@luiq54 Can this issue be closed now, or is there anything more that needs to be done for Windows support?

[mystchonky]

👍 Will push it when I get the chance.

Great!

Can this issue be closed now, or is there anything more that needs to be done for Windows support?

As for building and running the app is concerned, I havent faced any issues yet. In my opinion we should keep this issue open until binaries are publicly available or else someone else might open a similar issue

[smolck]

As for building and running the app is concerned, I havent faced any issues yet. In my opinion we should keep this issue open until binaries are publicly available or else someone else might open a similar issue

I just released v0.24.0; would you mind trying the binary/binaries to verify they work?

[mystchonky]

Oh cool!
The win-zip works flawlessly after unzipping! The standalone binary takes while to start but then it works properly.

I will close this issue now! 😁

[smolck]

Great! If you have any further problems please let me know!