Changed build to install the app uncompressed.

[mikeller]

Fixes #1056.

This changes the Windows and linux builds to install the app uncompressed. The released binaries won't increase in size, since they are compressed anyway, but the size on the hard drive will increase. The benefit of it is that the time it takes for the application to start is reduced.

[McGiverGim]

I saw the issue, but I have not such problem. My configurator starts in only 5 or 6 seconds. Why the user needs between 2 and 3 minutes? Maybe some change that we have made in the latest days?

[mikeller]

@McGiverGim: I am no Windows expert, but I think this can be caused by some virus scanners that insist on running a scan on the contents of compressed files once they are uncompressed, to make sure the compression wasn't used by viri to avoid detection.

[frozenskys]

@mikeller @McGiverGim Pretty much spot on - I'm using an SSD in this laptop however because I have customer data on this machine I'm running both endpoint encryption, and a commercial anti-virus solution. The issue seem to arise because nwjs unpacks the resources on every load and the AV kicks in. I'm seeing this with all nwjs apps such as the blheli configurator, and blackbox explorer (although they load in around 1.5 minutes due to less resources) - making this change in any one of those changes the load times to around 1 second.

[McGiverGim]

Yes, I don't like the solution, but if there is no other alternative, I suppose we must accept this.

[frozenskys]

@McGiverGim I'm not keen on this either and this is basically a nwjs issue, with the change here just a work around. I'll keep chasing it with the nwjs team but I think it will be a while before there is a proper fix - IMHO nwjs should just unpack on first use only and show a progress bar whilst it is doing it.

[mikeller]

@McGiverGim: I actually like the solution. Looking at today's storage costs, doing a 'better user experience for additional storage use' tradeoff seems to be the right thing to be doing. And doing the unpack during the installation (that can run in the background before the user needs the app) vs. doing it when the user wants to start the app for the first time and is waiting for it seems to be a reasonable choice as well.

[McGiverGim]

Yes, I think the same. We must do it. It seems needed for some users. Simply I prefer to have the things compressed, but the user experience is most important than the storage.

[McGiverGim]

@frozenskys do you know if the origin of the problem has been fixed at some way? Executing this uncompressed makes it faster, but makes the installation in windows slooooowww as hell... (it looks for files in all the folders to generate the uninstall information).

[frozenskys]

@McGiverGim I have just built the latest master with zip:true in the nwjs config and the install and startup seem to be fine again on these machines - I'm not sure if that is due to a move away from Trend AV or if that's due to some update to nwjs in the last year. I agree that the wait for the uninstall information is bad so maybe default to zip:true, and create an additional alternative zip:false build if you see further reports of AV issues?

[McGiverGim]

@mikeller what do you think? Maybe after the release of 10.6 we can revert it for the development builds and test for some months.

[mikeller]

@McGiverGim: Yes, we can give it another go - I suspect though we won't get to know if the problem still exists until after the following release, when users with all sorts of AV solutions will install and provide feedback.