On Windows Ned Looks for `HOME` System Variable

[RoyiAvital]

On Windows I get the following error:

By default, Windows does not set the HOME variable.

[nealmick]

The logic for the settings path is in the settings file manager.
On Mac it uses the home folder and copies settings files over to the home folder in ned directory. I think on windows the desired path is the local directory the app is running from. It is a bit complicated tho because the resources have to be copied at every build stage. If you build ned embed and then build some other application that its running inside, it starts to get complicated. There is some work on the testing branch to pass in a bunch more options to the ned embed instance when initializing. However a lot of this work is not public currently. It is possible to pass in a resource path and over ride the current logic to use a custom resource path, which is also very useful for packaged builds in deliverable applications. But that work is not public. If you want a quick fix just copy the resources with all the settings and icons stuff over to the path its trying to read, that would make it work if you just want it to run.

Just to clarify you have built this on windows and this is not the pre built version correct? as I believe the pre built windows version will use the local directory where the settings are stored? I am mainly testing on linux, windows support is a bit more buggy.

[RoyiAvital]

It is the latest pre built version.
It also seems the exe does not look for the settings folder in the correct path.

[nealmick]

I just redownloaded it and ran it again, its using the local download directory for me here:
[Settings] Using ned resource path: C:\Users\nealm\Downloads\ned/../ned [Font::loadFont] Successfully merged emoji font: C:\Users\nealm\Downloads\ned/../ned/fonts/seguiemj.ttf at size 13.3 [Settings] Using ned resource path: C:\Users\nealm\Downloads\ned/../ned [Settings] Using ned resource path: C:\Users\nealm\Downloads\ned/../ned

I would guess you maybe on windows 11 which may be different but that shouldn't matter, or some anti virus may be messing with it because sometimes it will quarantine the app not let it read files, because the app is not signed. other then that maybe ill test on a fresh windows 11 machine and see if I can reproduce later. However testing just now I was not able to reproduce issue. If you can provide anymore details about your system or environment that would be great.

[RoyiAvital]

It is not AV.
I use a script launcher to launch the exe.
It seems it does not look relative to the exe but relative to the cwd / pwd which could be different.

[nealmick]

Ah that makes perfect sense. Yea I suppose it shouldn't rely on the working dir, maybe I'll get around to fixing this. It should be relative to the executable not relative to where it's run.