[wix-devs] DisplayInternalUI in v4

[Sean Hall]

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.