Customize the time before the loading GIF shows up

[christianrondeau]

It's currently hardcoded to 4 seconds, which I think is way too much. I expect immediate feedback, and even though the app might start immediately, just the .NET JIT may be enough to make me ask myself the question: what is happening? Did it work?

I would personally set it to zero, and even if it just flickers, at least it gives a clue that something happened.

[stefanolson]

I agree.On the few occasions I have seen it it has turned up after my application is already running

[anaisbetts]

@stefanolson These are two separate bugs. I think that 4sec is the right time, but if it shows up after the app is running, either Squirrel events are being handled incorrectly (i.e. you're showing your app window in --squirrel-install), or something is going wrong in Update.exe (also entirely possible)

[stefanolson]

Yes, it's quite possible that they are bug related, funnily enough I'm seeing the animated gift now when I double click on setup.exe after the application is already installed... (and the application doesn't start up)

[peters]

Strange, we are installing a 70MB package on our old payment terminal series and they are slow as hell -> it takes longer than 4 seconds. Where is ze gif? :(

[peters]

So revisiting this one.. could you provide a screenshot for what the feature is supposed to be doing? One is installer takes about a minute to complete on a slow kiosk terminal and there are no unicorns? :(

[anaisbetts]

@peters I'll do you one better, here's a Demo:

http://cl.ly/0P1Y1l1S260V

That EXE installs Atom for Windows, and (hopefully!) shows the intended behavior

[peters]

Awesome! :D Why am i not seeing that animation? Or is the spinner beside the cursor you are talking about?

[peters]

atom === awesomesauce

[anaisbetts]

@peters That image should animate (i.e. you see the cursor moving around, tabs open and close - it's not?

[peters]

@paulcbetts Yup, that's what i'm seeing but not in my installers :(

[kevfromireland]

I would be up for making this configurable. I think I understand the rationale between not wanting it until after 4s by default, but would you accept a PR that made it opt-in configurable with 4s as the default?

[anaisbetts]

I would be up for making this configurable. I think I understand the rationale between not wanting it until after 4s by default, but would you accept a PR that made it opt-in configurable with 4s as the default?

I'll probably lower this to maybe 2sec, but I don't really want it to be configurable, if people want a non-custom number, they can use their fork

[daviseford]

+1 to this issue, I'd really like to see the ability to customize when the loadingGif is shown! Not being able to show it early makes users freak out about what's happening.

[demetris-manikas]

@paulcbetts Is there a reason that you don't want a hardcoded value to be configurable apart from having to write code to handle it?

[anaisbetts]

@demetris-manikas I'd rather just have code that works for everyone without configuration, especially because we also have no place to currently put this configuration

[develar]

I am with @paulcbetts but unfortunately windows is windows and we should show immediate response to user action — on OS X user after click get "Verifying" (DMG) or bouncing app icon in the dock (.app). So... when I will have time I will fix this issue to close electron-userland/electron-builder#374

[demetris-manikas]

especially because we also have no place to currently put this configuration
Fair enough.
@paulcbetts Still I don't get why an installer should not show anything to the user if the installation is fast. I am on the 0 seconds delay side and since users complain the code does not just work for everybody.
Thanks anyway.

[develar]

@demetris-manikas 0 time delay break "just run it" behaviour. If on click such progress indicator will be shown immediately and then quickly disappears — it is not good. Well, since it is windows, it may be ok, but ideally should be no progress indicator if installation performed quickly.

I'll probably lower this to maybe 2sec

I think, we can try to do it. In any case for me current behaviour is ok — well, I run windows in a virtual machine, but even in this case no noticeable delay.

[demetris-manikas]

@develar The same will happen if the installation lasts 4.2 seconds.
Just an idea. Would it be a problem to have a fixed minimum installation time of say 4 seconds with the gif visible from the begining? I don't believe anyone would complain that the installation lasts longer than expected.

[ghost]

Yes @demetris-manikas has the right idea. I've seen no app that installs under 4 seconds anyway. (Especially if you use electron-builder). So either do as he suggests, or make it all configurable;

• loadingGifStartTime
• minimumInstallationTime (if less than this, just pretend it's still ongoing and keep showing loading gif).

[develar]

@wesleywesley electron-userland/electron-builder#374 (comment) Delay is removed in the electron-builder fork of Squirrel.Windows.

[ghost]

@develar don't understand, you say it's removed but in the comment you also say its not possible to fix it. I have built with electron-builder but the loading gif is shown only after about 6 seconds. Are you saying this is with delay removed?

[develar]

@wesleywesley You missed word "correctly".

I have built with electron-builder but the loading gif is shown only after about 6 seconds. Are you saying this is with delay removed?

So, it means that bootstrap (pure C++) took 6 seconds to extract zip from exe and run update.exe. And only after that loading gif will be displayed (without any delay in our fork). "correctly" — exactly about it — well, maybe I will get rid of Squirrel.Windows bootstrap and will use 7z sfx sdk.... Well, it is windows.

[abuhenasobuj]

It's will be very good feature.
We can this feature to introducing our apps by GIF Animation.
Eg:
First I want to show an splash screen that took nearly 10 sec then installation will start & finished in few sec.

[fpadilha]

#889 should be in... We've done some testing (actually watching people create an account, download, install and use our software) and the results about that 4-second delay are horrible. Almost everyone tries to open the setup twice.

[Noah1989]

#889 does not resolve the issue, because no one is passing that parameter to Setup.exe. When releasifying, there is no mechanism to store config values. And adding that mechanism just for this feature would be overkill. However, there exists a very simple solution, that seems dumb at first, but is also very simplistic: AnimatedGifWindow.cs could just read the GIF metadata (comment or similar) and look for a special string there. That way you could specify the initial delay, and the change would be isolated to AnimatedGifWindow.cs. @anaisbetts What do you think? Would a PR using that approach have any chance of being merged?

[caesay]

I also had the view that the gif should show as early as possible. In my popular fork I initially solved this by having the C++ Setup.exe showing the gif window immediately upon opening. I've since refactored this slightly and the gif window is in C# again, however the only thing that Setup.exe extracts is the C# Update.exe binary, and then Update.exe shows the splash window immediately, so it should still be quite quick. It does not need to wait for the whole zip package to be extracted to disk.

[anaisbetts]

From 2015:

#77 (comment)

Nobody submitted that PR though! I would not accept an approach involving GIF metadata, that's crazytown. The reason the GIF does not show immediately is that because for small installs (which should be as many of your apps as possible!), the GIF would flicker then immediately disappear - it would seem like a Bug.

The goal is that, within N seconds of the user clicking Setup.exe (where N is a small number like 3!), the app opens. That's what the user wants! That's the reason they clicked Setup.exe, to use your app! As nice as your splash screen may be, the user does not want to admire it. The splash screen is an (important) compromise for people who are shipping big apps

[Noah1989]

Thanks @anaisbetts for the feedback. I was thinking way too complicated. What about this: Set the delay to zero automatically if the installer file size is big (say >100MB?). This way, the splash screen would open immediately for those who have problems with users opening the installer multiple times because the app is big. Would you be open to this approach? If so, I'll make a PR.

[caesay]

I would argue that neither a configuration option nor detecting the package size will be helpful. Even a relatively small package (eg. 20-50mb) can take upwards of 30s to install on a slow computer. In fact, just extracting the package to the disk for the first time is what takes up 90% of the install time. So really, no matter the configuration in this library, the splash screen will not show until very late if the package is large or the computer is slow, or both.

Having a splash screen flash for 0.5s is really not a problem. Especially if the app runs right afterwards. Not seeing a splash screen or any user feedback for 30+ seconds is a real problem. Especially since Setup.exe has no system mutex/locking, and there is a handful of installer code in Update.exe which is also not protected by a lock. Users will run the setup more than once, and it does cause problems.

The only real solution in my opinion is to show the splash screen as early as possible, before starting any difficult/expensive work, like unzipping the package. And that's how it works in my fork.

[Noah1989]

In fact, just extracting the package to the disk for the first time is what takes up 90% of the install time. So really, no matter the configuration in this library, the splash screen will not show until very late if the package is large or the computer is slow, or both.

I see this problem, too. I noticed that the delay is much longer than 4 seconds, so my proposed solution would not be of much help for my particular case of an especially huge app. @caesay fine, I'm convinced to use your fork instead :P