Squirrel
Ship a default updater UI
From the initial specs:
https://github.com/github/Shimmer/blob/master/specs/Scenarios.md
The library helps me check for updates, get the ChangeLog HTML to render, and if I'm really lazy, I can just call
UpdateManager.ShowUpdateNotification()and get a stock WPF dialog walking the user through the upgrade.
Do we want this? Or just provide a good sample app with bits for people to repurpose as they want.
I don't see a lot of value in providing default update UI as it should be easy to implement and different projects will want to integrate updating into their apps in different ways.
I have a documentation request. What is the RightWay™ to restart the app after applying updates? It isn't covered in https://github.com/github/Shimmer/wiki/How-do-updates-work%3F
Our main scenario is similar to ClickOnce: During app startup check for updates and apply them before the app gets running proper, this minimizes the number of people running older versions of our app. With Shimmer the app needs to start up to check for updates. Then it will need to relaunch itself with the latest version. From the user's perspective they should just run the app and it will be the latest version.
I assume if an app detects and applies updates during runtime the user could be asked to restart the app and the same relaunch code would run.
As a temporary solution i just added a simple myapp.restart.exe and referenced it with my main project. This should probably be a shimmer core feature. It's 4 lines of code. Or you can reference Winforms and call Application.Restart() if you're lazy.
I have a documentation request. What is the RightWay™ to restart the app after applying updates?
This isn't something I've actively investigated yet, and given all the mediocre ways you can apparently do that, I think it's something worth investigating.
Our main scenario is similar to ClickOnce: During app startup check for updates and apply them before the app gets running proper, this minimizes the number of people running older versions of our app.
There's a philosophical side to this too:
- always update the user when they start the app, to the detriment of taking a few minutes out of their day to download and apply the updates
- update in background while the user is working in the app, and remind the user to restart the application at the end, rather than disrupting their tasks
There's tradeoffs for both, but I'm happy to thrash this out over code samples for now (over in the Shimmer.Samples repo maybe), to see how hard it would be to support both modes inside the app.
@shiftkey Guess this is a low priority for you guys but are there any plans of freshing up the eye candy for the installer? You have mentioned in the 1.0 milestone that this was/maybe going to be used in 'Github for Windows'. Then its' safe to say that this is going to be taken care of?
An easy way to extend Shimmer would be doing it the same way as AppSetup. Then you would just have to derive from the "base" viewmodels: ErrorViewModel, InstallingViewModel, UninstallingViewModel and WelcomeViewModel. Then you would only need to change the presentation layer for each viewmodel. But you probably have a better way of doing it, i'm more of a GTK guy.
Guess this is a low priority for you guys but are there any plans of freshing up the eye candy for the installer?
I'll be revisiting this as part of the 0.9 release, but I don't expect significant overhaul of the UI/UX for the 1.0.
You have mentioned in the 1.0 milestone that this was/maybe going to be used in 'Github for Windows'. Then its' safe to say that this is going to be taken care of?
0.9 is all about customizing the installer experience - and I want Shimmer to be more than just something we use for deploying apps at GitHub - so I want your feedback and ideas on this
An easy way to extend Shimmer would be doing it the same way as AppSetup. Then you would just have to derive from the "base" viewmodels: ErrorViewModel, InstallingViewModel, UninstallingViewModel and WelcomeViewModel. Then you would only need to change the presentation layer for each viewmodel.
It depends on how much you want the ViewModels to do that isn't already covered by:
- deploying the app into the folder
- running AppSetup pieces
Doing visual things like animations and transitions probably doesn't require much change to the ViewModels.
Displaying additional data to the user probably requires changes to the ViewModels.
Making significant changes to the installer workflow would require lots of changes, not just to the ViewModels.
Doing visual things like animations and transitions probably doesn't require much change to the ViewModels.
This is the most important part.
Making significant changes to the installer workflow would require lots of changes , not just to the ViewModels.
I agree and it would be mostly pointless and introduce additional code complexity.
What would be nice though was that you are not allowed to change the installer's workflow, but instead you are able to add your own hooks instead:
public class AdvancedOption
{
public readonly AdvancedOptionType AdvancedOptionType;
public readonly AdvancedOptionInvocationType InvocationType;
public readonly Action Handler;
public readonly string OptionName;
public AdvancedOption(Action handler,
AdvancedOptionInvocationType invocationType, string optionName)
{
InvocationType = invocationType;
Handler = handler;
OptionName = optionName;
}
public AdvancedOption(AdvancedOptionType advancedOptionType)
{
AdvancedOptionType = advancedOptionType;
}
}
public enum AdvancedOptionInvocationType
{
BeforeInstallation,
AfterInstallation
}
public enum AdvancedOptionType
{
AddToWindowsBoot,
}
public class AutokollektWelcomeView : WelcomeViewModel
{
public override IEnumerable<AdvancedOption> AdvancedOptions()
{
return new List<AdvancedOption>
{
new AdvancedOption(AdvancedOptionType.AddToWindowsBoot),
new AdvancedOption(AutokollektAppSetup.WohoDoSomethingAwesome,
AdvancedOptionInvocationType.AfterInstallation,
"Do something awesome to my computer")
};
}
}
public class AutokollektAppSetup : AppSetup
{
public void OnAppInstall()
{
}
internal static void WohoDoSomethingAwesome()
{
}
}
@shiftkey thoughts?
Awesome sauce: Render installer ui in a Webview and use twitter bootstrap to customize the installer experience. Then bind a click handler to the relevant dom node! :dancers:
<button type="button" data-bind="as: Shimmer.Install"><span class="icon-thumbs-up"></span> Install</button>
I've created a custom installer UI that borrows heavily from the VS installer style.
You can take a look at it here: https://github.com/flagbug/Squirrel.Windows.MahApps
The only downside is, that it has a dependency on MahApps.Metro, but it shouldn't be a problem to create a stripped down version by removing all controls that aren't needed.
