[wix-devs] DisplayInternalUI in v4

[Sean Hall]

I updated the WIP at https://github.com/wixtoolset/web/pull/45 based on the
feedback in the meeting and what I implemented. I don't think there's any
open questions. I didn't end up asking wix-users since we decided
to support all the scenarios.

On Mon, May 18, 2020 at 3:01 AM Rob Mensching <rob at firegiant.com> wrote:

> We discussed this in the last meeting, were there any additional items
> needing covered:
> https://www.firegiant.com/blog/2020/5/13/wix-online-meeting-188-highlights/
>
> -----Original Message-----
> From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of Sean
> Hall via wix-devs
> Sent: Saturday, May 2, 2020 12:07 AM
> To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
> Cc: Sean Hall <r.sean.hall at gmail.com>
> Subject: Re: [wix-devs] DisplayInternalUI in v4
>
> I created a WIP for moving DisplayInternalUI out of the engine and into
> BalExtension here -
> https://wixtoolset.org/development/wips/6164-move-displayinternalui-from-core-to-bal/
> .
>
> I actually don't really care which approach we take for wixstdba. I chose
> #3 since that's the only one that would actually use the properties we had
> been talking about.
>
> Once it's reviewed here, I'll try to get feedback from wix-users.
>
> On Thu, Apr 2, 2020 at 6:13 AM Rob Mensching via wix-devs <
> wix-devs at lists.wixtoolset.org> wrote:
>
> > 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-Dec
> > ember/001454.html
> > ,
> >
> > http://lists.wixtoolset.org/pipermail/wix-devs-wixtoolset.org/2015-Oct
> > ober/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/
> > ____________________________________________________________________
> > WiX Toolset Developer Mailing List provided by FireGiant
> > http://www.firegiant.com/
> >
> ____________________________________________________________________
> WiX Toolset Developer Mailing List provided by FireGiant
> http://www.firegiant.com/
>