ZwiftLauncher loads and sits in the system tray on Windows, making it convenient to load Zwift when you want to ride, except when there’s a big update coming.
Nothing saps the energy to ride when you kit up and are standing over the bike, and then realize you have to wait 15 minutes for the client to download and install a new update.
If ZwiftLauncher had the ability to do the following, it would GREATLY enhance the experience:
Download + install updates
Download + install updates at {user-specified time}
Download but do not install updates
Do not download or install any updates (let user decide)
This way, as long as ZwiftLauncher is loaded and active, it can download or download and install updates prior to actually wanting to ride. This models very much how many other apps, including Microsoft Windows itself handles updates.
I think 1,3 and 4 would be a grand idea - 2 maybe, never sure how often that feature is used by people with other applications. 4 is supposed to be there now, but appears to be a tad broken.
One thing would be getting rid of the login screen, so launching Zwift is just a double click, then you get on setting your bike up. Rather than having to go through the login process.
David, I’ve tried your mac script but although the Zwift app is being activated the script isn’t populating the fields. The script is retrieving the values from the keychain but the Zwift app doesn’t seem to have the focus.
@Stuart: I’ll put some work into forcing focus to the Zwift windows for each command. Someone else reported something similar and he had to close some other resident app he had running and the code started working, un modified. But I’ll see if I can just force it regardless of what’s running.
Just a heads-up, my code already does activate the Zwift window, but the focus gets stolen after the activation, which I believe is because OS X Notifications are stealing the focus back. I’m going to force it at each event, to be sure they’re being fired into the right process, not just the one that was activated previously.
I found a slightly safer method, I’m going to test this morning and update my blog post to include that new code. I’ll re-post the newly updated link + code on Zwift Riders later for others to consume.
David - have you tried Stuarts change ? Seems to work here, wondering if the ‘activate application’ is not having the effect we might expect, whereas the explicit ‘activate’ command does… or somesuch.
I’ve updated the HOWTO with a bit of extra code that ensures that Zwift is the modal application before stuffing in the keystrokes. Feel free to use this new version:
I made another update late last night after working with another Zwift’er on Facebook and we discovered two important things:
1.) El Capitan steals focus IMMEDIATELY from every app that is launched. This doesn’t happen on my Yosemite machines and I don’t have an El Capitan machine to test it on, but it’s consistent. I’ve added code to accommodate that and now it should work on El Capitan, and
2.) There are different login dialogs for non-trial vs. trial users. I wrote the original code based on my own login, which was in trial mode for the last 60 days, so it would always fail for users who already exceeded their trial and tried to run it, because my code was expecting that second dialog to show up with the two buttons: “Join Now” and “Start Ride”. For non-trial users, that second dialog never shows up.
What I need to do is include code to detect the second dialog (if possible) and handle both cases independently.
Trial users: Fill in Username/Password, hit Enter, delay 3-5 seconds until second dialog paints, then click “Start Ride” on that second dialog.
Non-trial users: Fill in Username/Password, hit Enter. Nothing more is required.
It’ll take me a day or two to work out the kinks in that bit.
I can create a second script that works for trial users, and you can use that in the meantime, but that’s just a temporary workaround until I can automate this in a single script.