[wix-devs] DisplayInternalUI in v4

[Rob Mensching]

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/