If NWjs.AppFolder is called in a NWjs-App in Linux it gives the wrong path. It puts chrome-extension:// with an ChromeApp-Id in front of the path. It works fine with Windows.
Attach a Capx
Capx with two externels files:
https://drive.google.com/file/d/0B5FlDY ... sp=sharing
Description of Capx
The Capx displays the NWjs.AppFolder path in a Textbox. Where the path will be shown correct on all Systems. Then it tries to load a picture in a sprite from an external file and a text-file with the ajax-plugin.
If ajax loaded successful it will write an O.K, otherwise Error
Steps to Reproduce Bug
The Textbox displays the correct path, but no image is loaded and ajax reported an error.
Operating System and Service Pack
Windows 7 SP 1
Linux Mint 64 Bit
Construct 2 Version ID
r233 and nwjs 0.16
Anyone know if this is something one could possibly get around? I'm planning on to porting to mac/Linux and it's impossible to load external files because of this. :[
The expression returns the correct path - e.g. "/home/username/Desktop/". This is a valid path for the file system. The problem is if you make a request to this treating it as a URL - such as you do to issue an AJAX request and load an image - then it's routed through the browser URL resolution. This is not the same as a file path. It expects URLs of the form "https://www.scirra.com", but you pass it something like "/home/username/Desktop/test.txt". This looks like a relative URL (e.g. fetching "/folder/file.txt") so the request happens to be made relative to the current URL, which happens to be something based on chrome-extension:// for NW.js apps. The problem probably only does not happen on Windows because the different file path style with a drive letter unambiguously identifies a local path. You can force it to treat a path as a local URL by prefixing "file://". So your example actually starts working if you add "file://" before the request URLs. That's a nice easy workaround for the time being!
So far everything is actually working correctly. The real problem is confusion between file paths and URLs. We can't change AppFolder because adding "file://" is incorrect for actions that directly manipulate local files. But then you can't directly use AppFolder in a URL expression without prefixing "file://".
So I think the best solution is a new expression AppFolderURL, which has the "file://" part automatically included. Then you can use AppFolder for local file stuff, and AppFolderURL for anything treated as a URL. This will be added in the next build, but you don't need to wait, just add "file://" for now and it works.
Thanks Ashley, I did some tests in Ubuntu today and it looks like loading a text file via NWjs.ReadFile works fine without the "file:" prefix, but loading images into a Sprite via Load image from... requires prefix "file:/" (with just the single forward-slash). Will the next build make this consistent between the two objects, so I can just make a single "AppPath" text variable to use for all file loading?
— - no, because URLs and file paths are different things. The issue here is people confusing the two.
Develop games in your browser. Powerful, performant & highly capable.
Right, and both of what I mentioned above were file paths. One loaded a text file saved locally into a text object, the other loaded an image saved locally into a sprite. The former did not need the file:/ prefix, the latter did need it.
I suppose there might be a better way to load in a local text file than using NWjs.ReadFile that I am not aware of?