Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 03:35
    xujialiang opened #7138
  • Aug 21 11:09
    stale[bot] closed #6753
  • Aug 21 11:09
    stale[bot] closed #6774
  • Aug 20 20:53
    Bigbeto123 opened #7137
  • Aug 19 22:06
    gr1los opened #7136
  • Aug 19 11:01
    AshleyScirra opened #7135
  • Aug 18 10:41
    stale[bot] labeled #6774
  • Aug 18 10:41
    stale[bot] labeled #6753
  • Aug 18 06:01
    stale[bot] closed #6754
  • Aug 18 06:01
    stale[bot] closed #6739
  • Aug 18 06:01
    stale[bot] closed #6434
  • Aug 18 06:01
    stale[bot] closed #6499
  • Aug 15 20:20
    jinguix opened #7134
  • Aug 15 06:56
    yucolabjames closed #6756
  • Aug 15 06:28
    thebellum opened #7133
  • Aug 15 05:36
    stale[bot] labeled #6499
  • Aug 15 05:36
    stale[bot] labeled #6434
  • Aug 15 05:36
    stale[bot] labeled #6739
  • Aug 15 05:36
    stale[bot] labeled #6754
  • Aug 15 05:36
    stale[bot] labeled #6756
The Jared Wilcurt
@TheJaredWilcurt
When creating a new window you have an option called new_instance. This is set to false by default. If you set it to true then the new window will not have a shared instance of Node, so it will not be able to communicate to the original window via global
@coreyfarrell
Corey Farrell
@coreyfarrell
oh nice. so I can share any kind of object through that - like global.connection = new Websocket(...)?
The Jared Wilcurt
@TheJaredWilcurt
it's the same as storing something on the window object and it being globally accessible to everything in that window. Storing it on the global makes it globally accessible to all windows (and Node)
so, yes
Corey Farrell
@coreyfarrell
I thought I read something about needing to do something special to work with node.js code from the browser? sorry if I'm confused
The Jared Wilcurt
@TheJaredWilcurt
You can access Node from the DOM directly
<button onclick="var fs = require('fs'); console.log(fs.readdirSync('.'))">Log Directory</button>
Node code is very easy to work with
If you are using "main": "index.html" then you do not need to do anything special
if you are pointing to a URL, then you need to give that URL Node access
"main": "http://localhost:1234",
"node-remote": "http://localhost:1234"
Corey Farrell
@coreyfarrell
what about "main": "index.js"? my app will only be using network for fetch/WebSocket stuff, no navigating to remote URL's is planned.
The Jared Wilcurt
@TheJaredWilcurt
I have never seen any apps that actually needed to start from a JS file. What you probably want to do is use
"main": "index.html",
"node-main": "index.js"
You can start from a JS file, but again, I've never seen anyone with a valid reason to
node-main will run a JS file in the Node context prior to a window being opened. It is commonly used to start up a local webserver before the app launches
Corey Farrell
@coreyfarrell
cool, I'll keep that in mind
thanks for helping me with my questions! I'm working on migrating an application from xulrunner (yes I know I should have done this a few years ago). I tried using firefox --app but it was very unstable.
Richard Guay
@raguay
Is there a way to disable caching completely? It's cause a lot of issues in building.
The Jared Wilcurt
@TheJaredWilcurt
caching of what
@raguay
Richard Guay
@raguay
nwjs keeps a cache for macos at ~/Library/Caches/<name of project> and some caching at ~/Library/Application Support/<name of project>. When I compile, I have to remove those directories. But, even if I don't compile and leave those directories, the programs quits launching after a few time until I clean out those directories. I was wondering if NWjs had a automatic way of doing it. I can't delete them from the program because of file locks, so I have to do it as part of my build script (mask script runner). But, since it does have issues after several launches, I'm thinking I need a way for the program to do it.
The Jared Wilcurt
@TheJaredWilcurt
@raguay that's Chromium, not NW.js doing that. Those locations have to be created. They should not impact anything though. If you are having to clear them manually there is a problem with your setup or code
Richard Guay
@raguay
Okay....looking....
Richard Guay
@raguay
Okay, with a lot of searching (I've been looking into this issue for months now), I've found the problem. The chokidar nodejs library for watching files and directories is the issue. If I don't watch the files and directories I need to watch for change in the program, it launches all the time just fine. If I do watch them, it only launches every third or fourth times (sometime every other time). Removing the directories I mention above helps the odds of launching. To me, there is some type of race condition about using that library to watch files and directories. Just loading the library, but not activating a watch works fine. So, it's nothing to do with the activation of the library.
Has anyone else used the chokidar nodejs library with nw.js?
Richard Guay
@raguay
Okay. It is definitely a race condition. I used setTimeout() to start the file watching functions for two minutes after boot. It now runs all the time just fine. I then lowered it to one minute and it is still working fine. But, I can't seem to go lower than that (depending on system load). So, I'll just keep it at one minute.
Should I create an Issue for it, or is this something somewhat standard? Has anyone else seen anything like this?
Richard Guay
@raguay
I just tried the latest version ( I was still using v39) and it has the same issues. So far, I've only ran the SDK version. Should I test with the RunTime version to see if it has the same issues or do you think that it shouldn't matter?
The Jared Wilcurt
@TheJaredWilcurt
That's interesting. I've been using Chokidar for years with Scout-App. But only runs after user initialization. (they click a button and it starts watching their project folder for changes)
only issue I've had is with text editors and atomic saves
@raguay
Richard Guay
@raguay
Yea. I'm only having issues with it when trying to setup the watches during loading. With the time delay, it works great. Weird.
BTW: it has atomic save settings now. Is it still an issue?
jackdavies606
@jackdavies606
I’m trying (and failing) to build nw40, I'm getting as far as building Node (ninja -C out/Release node). It seems to be failing as the Chromium dependancy icu has been updated from nw39 and no longer contains /windows/icudt.dll which is required by the Node build. Has anyone come across this issue? Here’s the icu dependancy; https://chromium.googlesource.com/chromium/deps/icu/+refs . (Commit 8c67416 used by nw38 contains /windows/icudt.dll. Commit 64e5d7d used by branches > nw38 do not contain /windows/icudt.dll.)
The Jared Wilcurt
@TheJaredWilcurt
@raguay I have not updated to Chokidar 3 yet. Maybe using Chokidar 2 will solve your issue? if it does, then you should file a bug with them
truesolarflame
@truesolarflame
Ah ha! So this is where the nwjs community hangs out? Nice.
:)
So... I am trying to codesign with hardened runtime so I can get notarization on my Web2Exe mac build to avoid gatekeeper blocking and possibly get it on the Mac App Store. I am trying to add entitlements to my codesigning so my app can actually still run after signing. :\
truesolarflame
@truesolarflame
Anybody know what entitlements are needed for nwjs to run? Or do I just have to figure what I need by trial and error?
An example entitlements.xml or entitlements.plist file would be great. :D
The Jared Wilcurt
@TheJaredWilcurt
@truesolarflame I have not done code signing or put anything on the MAS. but there is documentation on the NW.js site and in the wiki around it
truesolarflame
@truesolarflame
So... I guess the entitlement file content found in this link are indeed the minimum required. Hmm. Perhaps my app needs a little more. Trial and error it is!
http://docs.nwjs.io/en/latest/For%20Users/Advanced/Support%20for%20Mac%20App%20Store/
Thanks for the reply.
truesolarflame
@truesolarflame
Got my build signed, notarized, and tested! :)
The Jared Wilcurt
@TheJaredWilcurt
:tada:
@truesolarflame was there anything you had to do that wasn't documented?
If so, could you create an issue on the NW.js website repo to have those items added (or make a PR if you want)
truesolarflame
@truesolarflame
I found this page helpful: nwjs/nw.js#7117
I wish I had seen it sooner. It would have saved me a lot of time mucking around Apple's cruddy documentation.
truesolarflame
@truesolarflame
However, the only entitlement I needed was com.apple.security.cs.allow-unsigned-executable-memory