The problem was raised before, but I'm in desperation and decided to make a solution myself.
Splash screens sometimes disappear too soon, sometimes too late because of fixed timeout.
Solution: Detect when the main application window shows up and hide the splash screen then. I think I can modify the NSIS plugin to make it work this way.
Question: John, will you rebuild your launchers to use modified plugin? It will require only (probably) removal of timeout and provision of the main window class name instead. And rebuild 
You are here
Splash screens
September 17, 2007 - 1:17pm
#1
Splash screens
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
Somehow Kubuntu (and maybe KDE desktop based distros) makes that. It makes the application icon bounce, near the mouse, until this is open (it doesn't works very well tough). I think that your idea is a very good idea (but I like more the KDE bouncing icon
, that's still a very good idea that I support and hope that keeps going).
____________________
The Blogger of Portimão or O Blogger de Portimão. Free your mind...
Blue is everything.
A bouncing icon has nothing to do with a splash screen.
Sometimes, the impossible can become possible, if you're awesome!
Remember, most of these apps have multiple instances, so there may already be a window of the same name in existence... so the plugin would have to ignore the currently running window and wait for another. Some apps will pass off from a new instance to the current one never creating a new window. There would need to be a min and a max timeout so that it isn't up there too short and not too long (at which point we can assume it didn't correctly launch). And some apps use GTK so they all have the same window class names.
In short, it gets pretty complicated pretty quickly. And, realistically, it's just a splash screen and not a big deal... they all work close enough, which is why I never bothered with any of the above. I've timed them out so that the splash will run just a tad long on a really fast drive (but not enough to be annoying) and just a tad short on a slow drive (but not enough so the user thinks it's dead).
If you can somehow solve all of the above issues without introducing additional bugs or overhead and are willing to license it back to the greater NSIS community under the same BSD license, then, yeah, I'd use it. But, honestly, it's quite a lot to trudge through and I don't think it's really worth the effort just to have a splash screen adjusted by a few hundred ms.
Sometimes, the impossible can become possible, if you're awesome!
Remember, most of these apps have multiple instances, so there may already be a window of the same name in existence
Give me main thread ID, process ID or a handle to the process and I will find the correct window.
Some apps will pass off from a new instance to the current one never creating a new window
I see no good solution :(.
The best I can think of is a special parameter that will hide the splash screen when the started app quit. Or maybe a switch that will make the splash screen use just normal timeout in case of existence of another window of this class.
There would need to be a min and a max timeout so that it isn't up there too short and not too long (at which point we can assume it didn't correctly launch).
No problem.
And some apps use GTK so they all have the same window class names.
It is the same problem as multiple instances. So probably no problem
I've timed them out so that the splash will run just a tad long on a really fast drive (but not enough to be annoying) and just a tad short on a slow drive (but not enough so the user thinks it's dead).
No hardcoded timing is good. Overloaded bluetooth drive / a pair of RAID-0 iRams...it can make a minute difference. That's what I want to change.
Of course, I'm going to release it under BSD license.
"Those people who think they know everything are a great annoyance to those of us who do." Asimov
The app launchers won't have handles to anything. All they can provide you is the main window's class name. That's it. Remember the splash is called many lines of code before the launcher attempts to launch the app, usually while it is processing settings files, checking for files in the right places, etc. That's the main reason I introduced the splashes way back when... because it would take several seconds to process Firefox's chrome files.
The current newadvsplash call is like this:
newadvsplash::show [/NOUNLOAD] Delay FadeIn FadeOut KeyColor [/BANNER] [/PASSIVE] [/NOCANCEL] FileNameI'd propose:
newadvsplash2::show [/NOUNLOAD] WindowClassToWaitFor MinDelay MaxDelay DelayAfterWindowDetected FadeIn FadeOut KeyColor [/BANNER] [/PASSIVE] [/NOCANCEL] FileNameWindowClassToWaitFor - The class name that the splash will watch for
MinDelay - The minimum time to show the splash
MaxDelay - The maximum time to show the splash
DelayAfterWindowDetected - The amount of time the splash will remain visible without fading after the window is detected
I think that would cover it.
Sometimes, the impossible can become possible, if you're awesome!
I think that recognizing app instance is an important thing.
Maybe another solution:
You would make 2 calls to the plugin. The first would just show the SS. The second, made after starting an app, enable the window creation dependent mode.
"Those people who think they know everything are a great annoyance to those of us who do." Asimov
Can't do that either. Several apps are launched with an ExecWait which means NSIS starts the app and sits there waiting for it to exit. I can't launch the app and then make a second call to your plugin in that case. That's 1/3 to 1/2 of all apps.
So, again, the plugin only gets a single call from the launcher and will not get the handle.
... told ya this gets really complicated really fast. I went through this whole process a year ago and decided it just wasn't worth it.
Sometimes, the impossible can become possible, if you're awesome!
Customized ExecWait?
"Those people who think they know everything are a great annoyance to those of us who do." Asimov
ExecWait is part of NSIS itself. That would mean a customized fork of NSIS. No way in hell that's happening.
Sometimes, the impossible can become possible, if you're awesome!
I know that this is internal. But I can write newadvsplash:ExecWait that works the same way the original does, but also sets the things I need.
"Those people who think they know everything are a great annoyance to those of us who do." Asimov
I don't want to substitute a tried and true, fully-supported NSIS feature for a 3rd party one that may break in later releases of NSIS... certainly not for the sake of something as minor as timing on splash screens.
As I've said, if it's a drop in replacement for newadvsplash which introduces no bugs or overhead and requires no additional coding or additional work in the launchers themselves, I'll use it. If it doesn't fulfill all of those requirements, I will not use it.
Sometimes, the impossible can become possible, if you're awesome!
Understood.
Got another idea. I can check whether the app instance creating the window is my child process. Should be enough.. and this way I don't need pid etc. I will write a quick-and-dirty-test-only-version soon
"Those people who think they know everything are a great annoyance to those of us who do." Asimov
I made it differently, I forgot I can ask NSIS to notify me when Exec or ExecWait is executed. Current limitation: the window must be created by the main thread (I never saw that program does it differently, but I don't check it with every tool in my hands
). It makes practically no overhead.
TODO:
Code cleanup, some internal tweaks, fixing possible bugs (it's not well tested).
Download
"Those people who think they know everything are a great annoyance to those of us who do." Asimov
In my opinion the current splash screen system is good and have no need to change it...
Please excuse me, I also hate bumps, I know they are prohibited here... But I hate even more when my work is wasted because a busy person didn't notice it...
"Those people who think they know everything are a great annoyance to those of us who do." Asimov