[wix-devs] DisplayInternalUI in v4

[Rob Mensching]

Yes, sounds right.

-----Original Message-----
From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of Bob Arnson via wix-devs
Sent: Tuesday, March 31, 2020 6:23 PM
To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
Cc: Bob Arnson <bob at firegiant.com>
Subject: Re: [wix-devs] DisplayInternalUI in v4

+1 on #3. As I recall, the BA would pass in well-known (albeit custom) properties and we'd modify WixUI dialogs to respect them.

-----Original Message-----
From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of Sean Hall via wix-devs
Sent: Tuesday, 31 March, 2020 20:59
To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
Cc: Sean Hall <r.sean.hall at gmail.com>
Subject: [wix-devs] DisplayInternalUI in v4

We've discussed several times about what to do about DisplayInternalUI in
v4 (
http://lists.wixtoolset.org/pipermail/wix-devs-wixtoolset.org/2019-December/001454.html,
http://lists.wixtoolset.org/pipermail/wix-devs-wixtoolset.org/2015-October/000112.html).
I've been looking through the wix-users list and users are asking for everything between DisplayInternalUI being configurable at runtime and wanting the full MSI UI for every operation (install/modify/repair/uninstall). It seems like there are 3 different approaches we can take.

1. Remove DisplayInternalUI entirely. This enforces the design decision for Burn that there should be one unified UI for the bundle (documented in http://robmensching.com/blog/posts/2012/6/25/b-is-for-bundle-and-thats-good-enough-for-me/
and http://www.joyofsetup.com/2013/07/05/burn-zero-one-or-n/).

2. Continue with the v3 design of DisplayInternalUI - allow the MSI UI to be shown, but the Burn engine will ensure that the user/MSI can only do what was planned. The basic idea to implement this approach is to expose MsiEngineCalculateInstallUiLevel as a BA message, but disallow certain UI levels when not doing an install. This satisfies some user requests but many want full MSI UI during maintenance operations, e.g. feature selection during Modify.

3. Allow the BA full control of the UI level of the MSI, even if that means the user/MSI ends up doing something other than what was planned. The basic idea to implement this approach is to expose MsiEngineCalculateInstallUiLevel as a BA message, and whatever else needs to be exposed in that message to support EmbeddedUI. This should satisfy all user requests, or at least enable them to build a BA that can do what they want.

IIRC in that discussion we had after we stopped recording the meeting, we had been leaning towards #3. In order to mitigate the potential for the user/MSI doing something other than planned, either Burn or the BA was going to set some MSI properties that WixUI could use to only enable the planned operation. I think we also considered that WixStdBA would no longer support showing MSI UI, and we would build a separate BA for that.

I want to take approach #3. I'm in favor of making the built-in BA's usable for most, and then if users hit a wall then they have the extensibility to do what they want.

For WixStdBA, I think we should basically keep it where it is - allow more flexibility like being able to have a condition for DisplayInternalUI but keep ensuring that the user/MSI can only do what was planned.

I'm interested in building another built-in BA that will allow showing the full MSI UI for every operation - basically try to hide the bundle UI whenever possible. This would be technically closer than WixStdBA to intended Burn of only one UI.
____________________________________________________________________
WiX Toolset Developer Mailing List provided by FireGiant http://www.firegiant.com/ ____________________________________________________________________
WiX Toolset Developer Mailing List provided by FireGiant http://www.firegiant.com/