New: HomeBank (Sep 03, 2023), Platform 26.2.1 (Sep 17, 2023)
450+ real apps (49GB), 1.1 billion downloads, Please donate.
Jack Haller, Advisor and Father of Our Founder, Has Passed Away
Sometimes apps take quite a while to startup. This time is also variable depending on whether they are running in live mode, speed of flash drives, etc.
It would be really helpful for the SplashTime parameter to support the ability for the splash to stay up until the application is visible or just about to be visible.
D.
It's not possible to do this. As you note, there's no fixed time that an app will take to launch, and so it would require extra code in the base applications to tell the launcher when they're ready - which isn't plausible at all. Besides which, having a splash screen for 1.2 seconds is one thing, but having it stay open on top of everything, blocking access to other windows underneath for ten or twenty seconds (granted, it will depend on the application) would be generally considered to be unacceptable. Apps with splash screens of their own that do that are almost always not system modal.
I guess what I'm looking for is an indication that something is happening. When the splash disappears after 2 seconds, but the application takes another 10 or more to launch, the user starts to wonder and possibly hits the icon a second time.
So I guess I'm really looking for a "Preparing your application to run" progress bar - but thought that a minor modification to the splash routines might do it.
Is there another existing solution or a new idea to cover this gap?
Thanks,
D.
As mentioned, the launcher has no idea how long it will be til the app is launched. The media has the biggest effect on the speed of launch with a difference between a hard drive launch and a slow flash drive launch being about 50x. Yes, 50 times difference. So, we can't calculate it ahead of time. And we can't tell how much work the app has to do to start nor how much is left because the splash is shown by the launcher, not the app. The whole reason we have the splash is to say "yes, you clicked it, it's now starting and will be up as soon as it is ready." It prevents people from clicking to start an app, waiting 20 seconds, thinking maybe they didn't click it, and clicking it again. The splash means you clicked it... now you have to wait. Clicking it again doesn't make sense.
John, thanks for taking interest in this.
Could the portableappsplatform.exe display a yellow popup notification in the tray / notification area saying "starting such-and-such application". Microsoft's App-V does this for the same reason (can't predict launch time).
Couldn't the platform watch which portable app I launched and then read the launcher.ini and watch for [Launch]:ProgramExecutable to know when to terminate the notification area message? Or possibly it could be responsible for displaying the splash? It would have to check that the instance it is looking for is a child of the portable launcher in case other instances are active or go active. If multiple portable instances are allowed, it could get the PID when it launches the portable launcher instance.
Could have a timeout value and the ability to disable the status notification on a per application or per platform basis.
A possible side benefit would be having the platform know or predict when something has gone wrong with the launch.
I assume you already have some cool tools to check for processes like this, but I could help with a building a WMI query if it would help.
Maybe this is one of those times the impossible can become possible 
Hope you're having a great holiday season!
My big concern with all this is that it's a decent amount of code work and maintenance for what I and Chris see as zero benefit. We already have a splash to indicate that the app is launching. On average and faster drives, the app will come up in under 30 seconds (nearly all apps well under that mark). So... why is all of this necessary? The user is already very clearly aware that the app is starting since the splash already appeared... and they'll only have to wait on average 5 or maybe 10 seconds at the outset for 90% of apps.
Adding additional information to popup tray icons and such is just information overkill and, even if we could do it with code... why? It doesn't add anything. And it would likely slow down the launch having it continuously checking for specific windows to come up.
And every app will have differently named windows come up, so we'd need to specifically watch for different things for each app. You can't monitor for the EXE to start, you need to wait for the window. So we've have to go through every app and determine the window name and constantly poll for it.
Bottom line is it's complicated, a decent amount of extra code to create, test and maintain, and even with all that, it doesn't add anything to the user experience.
John,
I understand that it may not be possible due to the sheer work and I appreciate your taking time to review the request.
Although you may not have the resources to address it, I feel that keeping users informed during long periods of processing or latency is a big benefit.
In technology in general a lot of attention is paid to the challenge of communicating "something is happening" to users when there would otherwise be no indication of such.
The example of the App-V client - which seems a good comparative case because it's entire lifeblood is demand run, install-less apps - is a good case study because of the tens of thousands of users who use it. It is deemed an essential feature and is on by default.
I know Microsoft has virtually unlimited resources, so I'm obviously not comparing platforms, but speaking to the relative importance of letting users know something is happening.
In regard to spamming the desktop with information overload, in Windows 7 Microsoft has addressed the tray icon overkill by making it "impossible" for software developers to force their icon to always display - but they have made the default to be for tray icon status messages to display unless the end user wishes to turn them off. Definitely not as obtrusive as splash screens and totally under user control.
Another creative way to avoid the complication of monitoring for windows might be to have the platform simply query for the total processor utilization of a portable launcher and it's child processes for a given period of time (so it does not pop at random or run forever) and display a "working..." notification status whenever the aggregate is above a certain threshold with a settle down time of several seconds (so it must settle before the notification clears). I'm sure there would be cases where apps have mini-hangs that make it less accurate - but once calibrated I bet the Pareto's law would apply and most times it would be accurate for most apps.
If you don't have time to consider this, no problem - I deeply appreciate all your hard work on the platform.
I did want to point out that there is good reason to consider it and there may be creative ways (besides those I've tried to noodle in this thread) to solve it that also meet your architectural desires for the platform.
D.
P.S. I could also lend a hand with any low level monitoring and timing testing if you decide to pursue it.
The user *already knows* something is happening. The splash screen comes up and the mouse changes a busy in background indicator (on Windows 7 anyway) and will usually remain that way until the app comes up. That's *TWO* indicators already. The fact that the PA.c Menu went away after the user clicked the icon makes it 3 indicators that the system is starting the app. Most apps will come up with the splash screen leaving or within a second or 2 after that. There are a small number of apps that take longer than that. Firefox for instance... which takes 5 seconds to show the splash and another 15 to come up from an average speed flash drive... during which the splash is shown and then the hourglass working in background.
Apps on Windows themselves may often take 10 seconds to launch from a cold start (including Firefox and other popular apps) and have no splash screen nor other indicator other than the mouse working in background. They have no need to add additional cues to the user that something is happening becuase the user already knows: they clicked something, the start menu went away and the mouse pointer is the partial hourglass... exactly the same as when a user launches an app from the PA.c Platform but they get a splash screen in addition to all that.
Monitoring for specific windows will not work. Monitoring the CPU usage of a given process will not work as many apps use the CPU both before and after displaying a window.
There is NO reason to over complicate things and invent a whole new paradigm of telling a user something is happening. The user already knows something is happening through a splash screen and the mouse working in the background, which is utilized by all other windows software. Anything above that is simply not necessary. No other apps do this except the one example you have of App-V which takes a very long time to start even from a hard drive because it is setting up a virtualized environment.
If there were a *no-cost at all* CPU-wise, launch-time, coding time and maintenance-wise way of timing the splash to disappear the instant the app is ready on all systems, I'd implement it. I would absolutely, positively not put a systray popup with words like 'starting...' in it. That just looks unprofessional and 'hacky' rather than a real professional app.
Like what John and Chris said, the only possible way is to recompile the actual app itself.
In all honesty, I would appreciate having this feature as well. There have been times when a program, for whatever reason, failed to open properly. I wasn't able to notice until I checked Task Manager after a few minutes. As a user, I think it would make sense to have a tray icon that appears until the program is finished loading.
I'm a bit hesitant to call this an essential feature given the amount of work that would need to be done and the marginal benefit that would be gained, but it would be far from useless to include.
Visit the Community page
Join our forums
Follow us on BlueSky