WIXFEAT:4149 - Add UninstallSuccess page to WixStdBA

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

WIXFEAT:4149 - Add UninstallSuccess page to WixStdBA

SeanHall
I just sent a pull request to v4.0 for WIXFEAT:4149 that adds a new page to WixStandardBA.  Can this be ported back to v3.9, or is it a breaking change?

------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.  Get
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: WIXFEAT:4149 - Add UninstallSuccess page to WixStdBA

Rob Mensching-7

We discussed this feature concept a long time ago. There was debate whether it was better to create a whole new page or make the controls on the page conditional.

 

I do not prefer this approach because, for example, do we now need an UninstallError page? The combinatorics could get unwieldy with this approach, not to mention loc if controls need to move around on the success page*s*.

 

_______________________________________________________________

FireGiant  |  Dedicated support for the WiX toolset  |  http://www.firegiant.com/

 

From: Sean Hall [mailto:[hidden email]]
Sent: Sunday, May 4, 2014 10:06 AM
To: WiX toolset developer mailing list
Subject: [WiX-devs] WIXFEAT:4149 - Add UninstallSuccess page to WixStdBA

 

I just sent a pull request to v4.0 for WIXFEAT:4149 that adds a new page to WixStandardBA.  Can this be ported back to v3.9, or is it a breaking change?


------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: WIXFEAT:4149 - Add UninstallSuccess page to WixStdBA

SeanHall
I think there needs to be some way to be able to customize the interface based on context, such as which action was taken.

What happened to the "make the controls on the page conditional" idea?


On Mon, May 5, 2014 at 2:54 PM, Rob Mensching <[hidden email]> wrote:

We discussed this feature concept a long time ago. There was debate whether it was better to create a whole new page or make the controls on the page conditional.

 

I do not prefer this approach because, for example, do we now need an UninstallError page? The combinatorics could get unwieldy with this approach, not to mention loc if controls need to move around on the success page*s*.

 

_______________________________________________________________

FireGiant  |  Dedicated support for the WiX toolset  |  http://www.firegiant.com/

 

From: Sean Hall [mailto:[hidden email]]
Sent: Sunday, May 4, 2014 10:06 AM
To: WiX toolset developer mailing list
Subject: [WiX-devs] WIXFEAT:4149 - Add UninstallSuccess page to WixStdBA

 

I just sent a pull request to v4.0 for WIXFEAT:4149 that adds a new page to WixStandardBA.  Can this be ported back to v3.9, or is it a breaking change?


------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
&#149; 3 signs your SCM is hindering your productivity
&#149; Requirements for releasing software faster
&#149; Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs



------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
&#149; 3 signs your SCM is hindering your productivity
&#149; Requirements for releasing software faster
&#149; Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: WIXFEAT:4149 - Add UninstallSuccess page to WixStdBA

Bob Arnson-6
On 05-May-14 18:07, Sean Hall wrote:
> I think there needs to be some way to be able to customize the
> interface based on context, such as which action was taken.

'Zackly. Making uninstall-specific page(s) just makes modify and repair
jealous.

> What happened to the "make the controls on the page conditional" idea?

Ideas are cheap. I believe ThmUtil supports it so it's just a small
matter of coding.

--
sig://boB
http://joyofsetup.com/


------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
&#149; 3 signs your SCM is hindering your productivity
&#149; Requirements for releasing software faster
&#149; Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: WIXFEAT:4149 - Add UninstallSuccess page to WixStdBA

SeanHall
WixStdBA creates its UI from a declarative theme that supports localizing the text in the theme.  That means that all of the messages must be provided during compile time, and really the only dynamic content WixStdBA can provide is error messages.  You can't just add the ability to specify different messages for the same control, because controls might need to move around based on which message(s) are showing.

There are 5 actions (install, modify, repair, uninstall, and layout) and 2 possible outcomes (success, failure) which means 10 potential pages.  Right now, WixStdBA is pretending it can accommodate all 5 actions with a single success and a single failure page.  I don't need to convince you that Uninstall needs its own messages.

It seems like there's only two options.  The first is to split the current 2 pages into 10.  The second is to add the ability to hide controls based on which action was taken, and then have 5 different versions of a control in a page.  Either way is going to require adding a fair amount of code to WixStdBA.  I personally would prefer breaking them into 10 pages over having 2 pages crammed with lots of overlapping controls.

------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
&#149; 3 signs your SCM is hindering your productivity
&#149; Requirements for releasing software faster
&#149; Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: WIXFEAT:4149 - Add UninstallSuccess page to WixStdBA

Bob Arnson-6
On 06-May-14 22:53, Sean Hall wrote:
> I don't need to convince you that Uninstall needs its own messages.

Actually you do. I'm not convinced it's needed. I'm only convinced some
people want it because they have it today. I'm also convinced that
uninstall isn't *that* special.

> It seems like there's only two options.  The first is to split the
> current 2 pages into 10.  The second is to add the ability to hide
> controls based on which action was taken, and then have 5 different
> versions of a control in a page.

Or add to ThmUtil the ability for a text-capable control to choose among
multiple strings based on conditions. Probably other options we could
come up with caffeinated around a whiteboard. :)

--
sig://boB
http://joyofsetup.com/


------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
&#149; 3 signs your SCM is hindering your productivity
&#149; Requirements for releasing software faster
&#149; Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: WIXFEAT:4149 - Add UninstallSuccess page to WixStdBA

Heath Stewart-3
In reply to this post by SeanHall
In response to Sean, seems the more robust thing is to make controls’ visibility conditional on variables since we already have a variable containing the operation. This is how VS's setup works. Granted it's built on WPF, but showing and hiding controls is a pretty fundamental behavior. Heck, even MSI dialogs support that.

- Heath from his Surface Pro

From: [hidden email]
Sent: ‎Tuesday‎, ‎May‎ ‎6‎, ‎2014 ‎9‎:‎17‎ ‎PM
To: [hidden email]

On 06-May-14 22:53, Sean Hall wrote:
> I don't need to convince you that Uninstall needs its own messages.

Actually you do. I'm not convinced it's needed. I'm only convinced some
people want it because they have it today. I'm also convinced that
uninstall isn't *that* special.

> It seems like there's only two options.  The first is to split the
> current 2 pages into 10.  The second is to add the ability to hide
> controls based on which action was taken, and then have 5 different
> versions of a control in a page.

Or add to ThmUtil the ability for a text-capable control to choose among
multiple strings based on conditions. Probably other options we could
come up with caffeinated around a whiteboard. :)

--
sig://boB
http://joyofsetup.com/


------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
&#149; 3 signs your SCM is hindering your productivity
&#149; Requirements for releasing software faster
&#149; Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs

------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
&#149; 3 signs your SCM is hindering your productivity
&#149; Requirements for releasing software faster
&#149; Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: WIXFEAT:4149 - Add UninstallSuccess page to WixStdBA

Bob Arnson-6
On 07-May-14 10:48, Heath Stewart wrote:
In response to Sean, seems the more robust thing is to make controls’ visibility conditional on variables since we already have a variable containing the operation. This is how VS's setup works. Granted it's built on WPF, but showing and hiding controls is a pretty fundamental behavior. Heck, even MSI dialogs support that.
I sympathize with his objection to having multiple overlapping controls; it makes it difficult to visualize with anything other than the full stack of bundle+WixStdBA.
-- 
sig://boB
http://joyofsetup.com/

------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
&#149; 3 signs your SCM is hindering your productivity
&#149; Requirements for releasing software faster
&#149; Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: WIXFEAT:4149 - Add UninstallSuccess page to WixStdBA

Rob Mensching-7
In reply to this post by Heath Stewart-3

Isn’t there only one success and error page in an MSI? I think something like what Heath said below with conditions to hide/show controls plus the ability to have text resolve variables would provide much of the same flexibility that MSI provides for it’s one success page and one error page.

 

It may be that we finally need to move the condition and variable system out of Burn and into dutil (so thmutil could access it easily), but that’s something I’ve proposed before. Or maybe thmutil can do it all with callbacks (i.e. please evaluate this string as true or false for me).

 

I think this is what Bob was mentioning about the whiteboard.

 

_______________________________________________________________

FireGiant  |  Dedicated support for the WiX toolset  |  http://www.firegiant.com/

 

From: Heath Stewart [mailto:[hidden email]]
Sent: Wednesday, May 7, 2014 7:48 AM
To: Windows Installer XML toolset developer mailing list
Subject: Re: [WiX-devs] WIXFEAT:4149 - Add UninstallSuccess page to WixStdBA

 

In response to Sean, seems the more robust thing is to make controls’ visibility conditional on variables since we already have a variable containing the operation. This is how VS's setup works. Granted it's built on WPF, but showing and hiding controls is a pretty fundamental behavior. Heck, even MSI dialogs support that.

 

- Heath from his Surface Pro

 

From: [hidden email]
Sent: ‎Tuesday‎, ‎May‎ ‎6‎, ‎2014 ‎9‎:‎17‎ ‎PM
To: [hidden email]

 

On 06-May-14 22:53, Sean Hall wrote:
> I don't need to convince you that Uninstall needs its own messages.

Actually you do. I'm not convinced it's needed. I'm only convinced some
people want it because they have it today. I'm also convinced that
uninstall isn't *that* special.

> It seems like there's only two options.  The first is to split the
> current 2 pages into 10.  The second is to add the ability to hide
> controls based on which action was taken, and then have 5 different
> versions of a control in a page.

Or add to ThmUtil the ability for a text-capable control to choose among
multiple strings based on conditions. Probably other options we could
come up with caffeinated around a whiteboard. :)

--
sig://boB
http://joyofsetup.com/


------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
&#149; 3 signs your SCM is hindering your productivity
&#149; Requirements for releasing software faster
&#149; Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs


------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
&#149; 3 signs your SCM is hindering your productivity
&#149; Requirements for releasing software faster
&#149; Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: WIXFEAT:4149 - Add UninstallSuccess page to WixStdBA

SeanHall
In reply to this post by Bob Arnson-6
    Bob: I'm also convinced that uninstall isn't *that* special.

Well, I guess I can try to convince you :) It's special because if you want to say anything more than "Success" and "Restart Required", it's impossible to have it make sense after an install and an uninstall.  I would say that only setup developers think of "Setup" including install, modify, repair, and uninstall so saying "Setup Successful" after uninstall is confusing to most people.  The default restart message for the Success page is "You must restart your computer before you can use the software.", which is just wrong for uninstall.

    Rob: Isn’t there only one success and error page in an MSI? 

Didn't I see a discussion with you and Neil about being able to improve on 90's UI? :)  If we don't add pages, then ThmViewer is going to have to be updated to let you modify the environment so that you can do something about all of the overlapping controls.

    Rob: I think something like what Heath said below with conditions to hide/show controls plus the ability to have text resolve variables...

It's starting to sound like this is definitely the way to go.

    Rob: It may be that we finally need to move the condition and variable system out of Burn and into dutil (so thmutil could access it easily), but that’s something I’ve proposed before. Or maybe thmutil can do it all with callbacks (i.e. please evaluate this string as true or false for me).

I don't think moving it into dutil is a bad idea, but I don't see what that gets you here.  Since the engine is the one that has the values for all the variables, thmutil will have to depend on callbacks (or a COM interface, or ...).

I don't have time to work on this big of a feature for 3.9, I'm more interested in getting 3249 and 4161 in there.

------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
&#149; 3 signs your SCM is hindering your productivity
&#149; Requirements for releasing software faster
&#149; Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: WIXFEAT:4149 - Add UninstallSuccess page to WixStdBA

Bob Arnson-6
In reply to this post by Rob Mensching-7
On 07-May-14 12:49, Rob Mensching wrote:
I think this is what Bob was mentioning about the whiteboard.

Kinda exactly. :)
-- 
sig://boB
http://joyofsetup.com/

------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
&#149; 3 signs your SCM is hindering your productivity
&#149; Requirements for releasing software faster
&#149; Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: WIXFEAT:4149 - Add UninstallSuccess page to WixStdBA

Bob Arnson-6
In reply to this post by SeanHall
On 07-May-14 19:54, Sean Hall wrote:
> Well, I guess I can try to convince you :) It's special because if you
> want to say anything more than "Success" and "Restart Required", it's
> impossible to have it make sense after an install and an uninstall. I
> would say that only setup developers think of "Setup" including
> install, modify, repair, and uninstall so saying "Setup Successful"
> after uninstall is confusing to most people.

I'd say it's just as confusing for modify and repair. (That's my
objection to an uninstall-only fix.)

> The default restart message for the Success page is "You must restart
> your computer before you can use the software.", which is just wrong
> for uninstall.

Agreed.

>
> Rob: Isn’t there only one success and error page in an MSI?
>
> Didn't I see a discussion with you and Neil about being able to
> improve on 90's UI? :)

WixUI gets away with it because if you uninstall from ARP, you don't get
any kind of success dialog.

--
sig://boB
http://joyofsetup.com/


------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
&#149; 3 signs your SCM is hindering your productivity
&#149; Requirements for releasing software faster
&#149; Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: WIXFEAT:4149 - Add UninstallSuccess page to WixStdBA

Neil Sleightholm
In reply to this post by SeanHall
>> so saying "Setup Successful" after uninstall is confusing to most people. 

+1 – I get lots of complaints about this, IMO is makes no sense.

Neil

    Bob: I'm also convinced that uninstall isn't *that* special.

Well, I guess I can try to convince you :) It's special because if you want to say anything more than "Success" and "Restart Required", it's impossible to have it make sense after an install and an uninstall.  I would say that only setup developers think of "Setup" including install, modify, repair, and uninstall so saying "Setup Successful" after uninstall is confusing to most people.  The default restart message for the Success page is "You must restart your computer before you can use the software.", which is just wrong for uninstall.

    Rob: Isn’t there only one success and error page in an MSI? 

Didn't I see a discussion with you and Neil about being able to improve on 90's UI? :)  If we don't add pages, then ThmViewer is going to have to be updated to let you modify the environment so that you can do something about all of the overlapping controls.

    Rob: I think something like what Heath said below with conditions to hide/show controls plus the ability to have text resolve variables...

It's starting to sound like this is definitely the way to go.

    Rob: It may be that we finally need to move the condition and variable system out of Burn and into dutil (so thmutil could access it easily), but that’s something I’ve proposed before. Or maybe thmutil can do it all with callbacks (i.e. please evaluate this string as true or false for me).

I don't think moving it into dutil is a bad idea, but I don't see what that gets you here.  Since the engine is the one that has the values for all the variables, thmutil will have to depend on callbacks (or a COM interface, or ...).

I don't have time to work on this big of a feature for 3.9, I'm more interested in getting 3249 and 4161 in there.

------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
&#149; 3 signs your SCM is hindering your productivity
&#149; Requirements for releasing software faster
&#149; Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: WIXFEAT:4149 - Add UninstallSuccess page to WixStdBA

Hoover, Jacob

Could this be as simple as supporting a Visible/Enabled attribute on Text/Hypertext elements? We could then evaluate the attribute when changing pages, and the attribute could contain references to burn variables.

 

Another option (that I really like) would be to introduce a <Content /> element that could be a child of the Text/Button controls and could support a condition on it.  Ex:

    <Page Name="Success">

        <Text X="11" Y="80" Width="-11" Height="30" FontId="2" DisablePrefix="yes">

                 <Content Condition=”WixBundleAction = 2”>#(loc.LayoutSuccessHeader)</Content>

                 <Content Condition=”WixBundleAction = 3”>#(loc.UninstallSuccessHeader)</Content>

                 <Content Condition=”WixBundleAction = 5”>#(loc.ModifySuccessHeader)</Content>

                 <Content Condition=”WixBundleAction = 6”>#(loc.RepairSuccessHeader)</Content>

                 <Content>#(loc.SuccessHeader)</Content>

         </Text>

 

 

Jacob

From: Neil Sleightholm [mailto:[hidden email]]
Sent: Thursday, May 08, 2014 1:40 AM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] WIXFEAT:4149 - Add UninstallSuccess page to WixStdBA

 

>> so saying "Setup Successful" after uninstall is confusing to most people. 

 

+1 – I get lots of complaints about this, IMO is makes no sense.

 

Neil

 

    Bob: I'm also convinced that uninstall isn't *that* special.

Well, I guess I can try to convince you :) It's special because if you want to say anything more than "Success" and "Restart Required", it's impossible to have it make sense after an install and an uninstall.  I would say that only setup developers think of "Setup" including install, modify, repair, and uninstall so saying "Setup Successful" after uninstall is confusing to most people.  The default restart message for the Success page is "You must restart your computer before you can use the software.", which is just wrong for uninstall.

 

    Rob: Isn’t there only one success and error page in an MSI? 

 

Didn't I see a discussion with you and Neil about being able to improve on 90's UI? :)  If we don't add pages, then ThmViewer is going to have to be updated to let you modify the environment so that you can do something about all of the overlapping controls.

 

    Rob: I think something like what Heath said below with conditions to hide/show controls plus the ability to have text resolve variables...

 

It's starting to sound like this is definitely the way to go.

 

    Rob: It may be that we finally need to move the condition and variable system out of Burn and into dutil (so thmutil could access it easily), but that’s something I’ve proposed before. Or maybe thmutil can do it all with callbacks (i.e. please evaluate this string as true or false for me).

 

I don't think moving it into dutil is a bad idea, but I don't see what that gets you here.  Since the engine is the one that has the values for all the variables, thmutil will have to depend on callbacks (or a COM interface, or ...).

 

I don't have time to work on this big of a feature for 3.9, I'm more interested in getting 3249 and 4161 in there.


------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
&#149; 3 signs your SCM is hindering your productivity
&#149; Requirements for releasing software faster
&#149; Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: WIXFEAT:4149 - Add UninstallSuccess page to WixStdBA

Heath Stewart-3
In reply to this post by SeanHall
Would be a great time to fix a few issues that weren't implemented according to spec as well, like that null variables from failed searches should resolve as false or coerce as their defaults when compared to another type (i.e. a failed version search should evaluate as true when compared to an empty string or 0). Breaking/fixing this in v4 should be fine, right?

Sent from my Windows Phone

From: [hidden email]
Sent: ‎5/‎7/‎2014 9:53 AM
To: [hidden email]
Subject: Re: [WiX-devs] WIXFEAT:4149 - Add UninstallSuccess page to WixStdBA

Isn’t there only one success and error page in an MSI? I think something like what Heath said below with conditions to hide/show controls plus the ability to have text resolve variables would provide much of the same flexibility that MSI provides for it’s one success page and one error page.

 

It may be that we finally need to move the condition and variable system out of Burn and into dutil (so thmutil could access it easily), but that’s something I’ve proposed before. Or maybe thmutil can do it all with callbacks (i.e. please evaluate this string as true or false for me).

 

I think this is what Bob was mentioning about the whiteboard.

 

_______________________________________________________________

FireGiant  |  Dedicated support for the WiX toolset  |  http://www.firegiant.com/

 

From: Heath Stewart [mailto:[hidden email]]
Sent: Wednesday, May 7, 2014 7:48 AM
To: Windows Installer XML toolset developer mailing list
Subject: Re: [WiX-devs] WIXFEAT:4149 - Add UninstallSuccess page to WixStdBA

 

In response to Sean, seems the more robust thing is to make controls’ visibility conditional on variables since we already have a variable containing the operation. This is how VS's setup works. Granted it's built on WPF, but showing and hiding controls is a pretty fundamental behavior. Heck, even MSI dialogs support that.

 

- Heath from his Surface Pro

 

From: [hidden email]
Sent: ‎Tuesday‎, ‎May‎ ‎6‎, ‎2014 ‎9‎:‎17‎ ‎PM
To: [hidden email]

 

On 06-May-14 22:53, Sean Hall wrote:
> I don't need to convince you that Uninstall needs its own messages.

Actually you do. I'm not convinced it's needed. I'm only convinced some
people want it because they have it today. I'm also convinced that
uninstall isn't *that* special.

> It seems like there's only two options.  The first is to split the
> current 2 pages into 10.  The second is to add the ability to hide
> controls based on which action was taken, and then have 5 different
> versions of a control in a page.

Or add to ThmUtil the ability for a text-capable control to choose among
multiple strings based on conditions. Probably other options we could
come up with caffeinated around a whiteboard. :)

--
sig://boB
http://joyofsetup.com/


------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
&#149; 3 signs your SCM is hindering your productivity
&#149; Requirements for releasing software faster
&#149; Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs


------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
&#149; 3 signs your SCM is hindering your productivity
&#149; Requirements for releasing software faster
&#149; Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs

------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
&#149; 3 signs your SCM is hindering your productivity
&#149; Requirements for releasing software faster
&#149; Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: WIXFEAT:4149 - Add UninstallSuccess page to WixStdBA

Neil Sleightholm
In reply to this post by Hoover, Jacob

+1 for <Content/> I can see that being useful in other places too.

 

Neil

 

From: Hoover, Jacob [mailto:[hidden email]]
Sent: 08 May 2014 15:38
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] WIXFEAT:4149 - Add UninstallSuccess page to WixStdBA

 

Could this be as simple as supporting a Visible/Enabled attribute on Text/Hypertext elements? We could then evaluate the attribute when changing pages, and the attribute could contain references to burn variables.

 

Another option (that I really like) would be to introduce a <Content /> element that could be a child of the Text/Button controls and could support a condition on it.  Ex:

    <Page Name="Success">

        <Text X="11" Y="80" Width="-11" Height="30" FontId="2" DisablePrefix="yes">

                 <Content Condition=”WixBundleAction = 2”>#(loc.LayoutSuccessHeader)</Content>

                 <Content Condition=”WixBundleAction = 3”>#(loc.UninstallSuccessHeader)</Content>

                 <Content Condition=”WixBundleAction = 5”>#(loc.ModifySuccessHeader)</Content>

                 <Content Condition=”WixBundleAction = 6”>#(loc.RepairSuccessHeader)</Content>

                 <Content>#(loc.SuccessHeader)</Content>

         </Text>

 

 

Jacob

From: Neil Sleightholm [[hidden email]]
Sent: Thursday, May 08, 2014 1:40 AM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] WIXFEAT:4149 - Add UninstallSuccess page to WixStdBA

 

>> so saying "Setup Successful" after uninstall is confusing to most people. 

 

+1 – I get lots of complaints about this, IMO is makes no sense.

 

Neil

 

    Bob: I'm also convinced that uninstall isn't *that* special.

Well, I guess I can try to convince you :) It's special because if you want to say anything more than "Success" and "Restart Required", it's impossible to have it make sense after an install and an uninstall.  I would say that only setup developers think of "Setup" including install, modify, repair, and uninstall so saying "Setup Successful" after uninstall is confusing to most people.  The default restart message for the Success page is "You must restart your computer before you can use the software.", which is just wrong for uninstall.

 

    Rob: Isn’t there only one success and error page in an MSI? 

 

Didn't I see a discussion with you and Neil about being able to improve on 90's UI? :)  If we don't add pages, then ThmViewer is going to have to be updated to let you modify the environment so that you can do something about all of the overlapping controls.

 

    Rob: I think something like what Heath said below with conditions to hide/show controls plus the ability to have text resolve variables...

 

It's starting to sound like this is definitely the way to go.

 

    Rob: It may be that we finally need to move the condition and variable system out of Burn and into dutil (so thmutil could access it easily), but that’s something I’ve proposed before. Or maybe thmutil can do it all with callbacks (i.e. please evaluate this string as true or false for me).

 

I don't think moving it into dutil is a bad idea, but I don't see what that gets you here.  Since the engine is the one that has the values for all the variables, thmutil will have to depend on callbacks (or a COM interface, or ...).

 

I don't have time to work on this big of a feature for 3.9, I'm more interested in getting 3249 and 4161 in there.


------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
&#149; 3 signs your SCM is hindering your productivity
&#149; Requirements for releasing software faster
&#149; Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: WIXFEAT:4149 - Add UninstallSuccess page to WixStdBA

Bob Arnson-6
In reply to this post by Heath Stewart-3
On 08-May-14 10:53, Heath Stewart wrote:
Would be a great time to fix a few issues that weren't implemented according to spec as well, like that null variables from failed searches should resolve as false or coerce as their defaults when compared to another type (i.e. a failed version search should evaluate as true when compared to an empty string or 0). Breaking/fixing this in v4 should be fine, right?

What are the chances that would break existing expressions? One way to ensure nobody used WiX v4.0 would be to say you have to go through and "fix" your painstakingly-crafted complex expressions.
-- 
sig://boB
http://joyofsetup.com/

------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
&#149; 3 signs your SCM is hindering your productivity
&#149; Requirements for releasing software faster
&#149; Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: WIXFEAT:4149 - Add UninstallSuccess page to WixStdBA

Hoover, Jacob
In reply to this post by Neil Sleightholm

If anyone is brave, I have a proof of concept functioning for controls within a page with conditional  Content. (You’ll have to customize your theme to test it, and it only works on the controls within the page - not the application controls.)

 

https://github.com/jchoover/wix3/tree/WIXFEAT4149

 

 

 

From: Neil Sleightholm [mailto:[hidden email]]
Sent: Thursday, May 08, 2014 11:03 AM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] WIXFEAT:4149 - Add UninstallSuccess page to WixStdBA

 

+1 for <Content/> I can see that being useful in other places too.

 

Neil

 

From: Hoover, Jacob [[hidden email]]
Sent: 08 May 2014 15:38
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] WIXFEAT:4149 - Add UninstallSuccess page to WixStdBA

 

Could this be as simple as supporting a Visible/Enabled attribute on Text/Hypertext elements? We could then evaluate the attribute when changing pages, and the attribute could contain references to burn variables.

 

Another option (that I really like) would be to introduce a <Content /> element that could be a child of the Text/Button controls and could support a condition on it.  Ex:

    <Page Name="Success">

        <Text X="11" Y="80" Width="-11" Height="30" FontId="2" DisablePrefix="yes">

                 <Content Condition=”WixBundleAction = 2”>#(loc.LayoutSuccessHeader)</Content>

                 <Content Condition=”WixBundleAction = 3”>#(loc.UninstallSuccessHeader)</Content>

                 <Content Condition=”WixBundleAction = 5”>#(loc.ModifySuccessHeader)</Content>

                 <Content Condition=”WixBundleAction = 6”>#(loc.RepairSuccessHeader)</Content>

                 <Content>#(loc.SuccessHeader)</Content>

         </Text>

 

 

Jacob

From: Neil Sleightholm [[hidden email]]
Sent: Thursday, May 08, 2014 1:40 AM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] WIXFEAT:4149 - Add UninstallSuccess page to WixStdBA

 

>> so saying "Setup Successful" after uninstall is confusing to most people. 

 

+1 – I get lots of complaints about this, IMO is makes no sense.

 

Neil

 

    Bob: I'm also convinced that uninstall isn't *that* special.

Well, I guess I can try to convince you :) It's special because if you want to say anything more than "Success" and "Restart Required", it's impossible to have it make sense after an install and an uninstall.  I would say that only setup developers think of "Setup" including install, modify, repair, and uninstall so saying "Setup Successful" after uninstall is confusing to most people.  The default restart message for the Success page is "You must restart your computer before you can use the software.", which is just wrong for uninstall.

 

    Rob: Isn’t there only one success and error page in an MSI? 

 

Didn't I see a discussion with you and Neil about being able to improve on 90's UI? :)  If we don't add pages, then ThmViewer is going to have to be updated to let you modify the environment so that you can do something about all of the overlapping controls.

 

    Rob: I think something like what Heath said below with conditions to hide/show controls plus the ability to have text resolve variables...

 

It's starting to sound like this is definitely the way to go.

 

    Rob: It may be that we finally need to move the condition and variable system out of Burn and into dutil (so thmutil could access it easily), but that’s something I’ve proposed before. Or maybe thmutil can do it all with callbacks (i.e. please evaluate this string as true or false for me).

 

I don't think moving it into dutil is a bad idea, but I don't see what that gets you here.  Since the engine is the one that has the values for all the variables, thmutil will have to depend on callbacks (or a COM interface, or ...).

 

I don't have time to work on this big of a feature for 3.9, I'm more interested in getting 3249 and 4161 in there.


------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
&#149; 3 signs your SCM is hindering your productivity
&#149; Requirements for releasing software faster
&#149; Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: WIXFEAT:4149 - Add UninstallSuccess page to WixStdBA

Tobias Erichsen-2
Hi everyone,

I was wondering if that would be something that we could put into 3.10?

I also get quite a few complaints that the success-page of uninstall is
a bit puzzling...

Best regards,
Tobias


Von: Hoover, Jacob [[hidden email]]
Gesendet: Donnerstag, 8. Mai 2014 22:18
Bis: WiX toolset developer mailing list
Betreff: Re: [WiX-devs] WIXFEAT:4149 - Add UninstallSuccess page to WixStdBA

If anyone is brave, I have a proof of concept functioning for controls within a page with conditional  Content. (You’ll have to customize your theme to test it, and it only works on the controls within the page - not the application controls.)

 

https://github.com/jchoover/wix3/tree/WIXFEAT4149

 

 

 

From: Neil Sleightholm [mailto:[hidden email]]
Sent: Thursday, May 08, 2014 11:03 AM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] WIXFEAT:4149 - Add UninstallSuccess page to WixStdBA

 

+1 for <Content/> I can see that being useful in other places too.

 

Neil

 

From: Hoover, Jacob [[hidden email]]
Sent: 08 May 2014 15:38
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] WIXFEAT:4149 - Add UninstallSuccess page to WixStdBA

 

Could this be as simple as supporting a Visible/Enabled attribute on Text/Hypertext elements? We could then evaluate the attribute when changing pages, and the attribute could contain references to burn variables.

 

Another option (that I really like) would be to introduce a <Content /> element that could be a child of the Text/Button controls and could support a condition on it.  Ex:

    <Page Name="Success">

        <Text X="11" Y="80" Width="-11" Height="30" FontId="2" DisablePrefix="yes">

                 <Content Condition=”WixBundleAction = 2”>#(loc.LayoutSuccessHeader)</Content>

                 <Content Condition=”WixBundleAction = 3”>#(loc.UninstallSuccessHeader)</Content>

                 <Content Condition=”WixBundleAction = 5”>#(loc.ModifySuccessHeader)</Content>

                 <Content Condition=”WixBundleAction = 6”>#(loc.RepairSuccessHeader)</Content>

                 <Content>#(loc.SuccessHeader)</Content>

         </Text>

 

 

Jacob

From: Neil Sleightholm [[hidden email]]
Sent: Thursday, May 08, 2014 1:40 AM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] WIXFEAT:4149 - Add UninstallSuccess page to WixStdBA

 

>> so saying "Setup Successful" after uninstall is confusing to most people. 

 

+1 – I get lots of complaints about this, IMO is makes no sense.

 

Neil

 

    Bob: I'm also convinced that uninstall isn't *that* special.

Well, I guess I can try to convince you :) It's special because if you want to say anything more than "Success" and "Restart Required", it's impossible to have it make sense after an install and an uninstall.  I would say that only setup developers think of "Setup" including install, modify, repair, and uninstall so saying "Setup Successful" after uninstall is confusing to most people.  The default restart message for the Success page is "You must restart your computer before you can use the software.", which is just wrong for uninstall.

 

    Rob: Isn’t there only one success and error page in an MSI? 

 

Didn't I see a discussion with you and Neil about being able to improve on 90's UI? :)  If we don't add pages, then ThmViewer is going to have to be updated to let you modify the environment so that you can do something about all of the overlapping controls.

 

    Rob: I think something like what Heath said below with conditions to hide/show controls plus the ability to have text resolve variables...

 

It's starting to sound like this is definitely the way to go.

 

    Rob: It may be that we finally need to move the condition and variable system out of Burn and into dutil (so thmutil could access it easily), but that’s something I’ve proposed before. Or maybe thmutil can do it all with callbacks (i.e. please evaluate this string as true or false for me).

 

I don't think moving it into dutil is a bad idea, but I don't see what that gets you here.  Since the engine is the one that has the values for all the variables, thmutil will have to depend on callbacks (or a COM interface, or ...).

 

I don't have time to work on this big of a feature for 3.9, I'm more interested in getting 3249 and 4161 in there.


------------------------------------------------------------------------------

_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: WIXFEAT:4149 - Add UninstallSuccess page to WixStdBA

Rob Mensching-7

Jacob, what about putting the condition on other elements? That way one could disable controls (and there is already a HideWhenDisabled bit)?  Technically, if conditions were allowed on the existing elements then we wouldn’t need “Content” elements… but one would need to duplicate all the attributes without the Content concept.  So I’m mixed there.

 

Tobias, the change looks like it can be done additive so it could be back ported to v3.x if Jacob chooses to do the work (looks like this is actually of the wix3 branch now).

 

_______________________________________________________________

FireGiant  |  Dedicated support for the WiX toolset  |  http://www.firegiant.com/

 

From: Tobias Erichsen [mailto:[hidden email]]
Sent: Wednesday, November 5, 2014 1:13 AM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] WIXFEAT:4149 - Add UninstallSuccess page to WixStdBA

 

Hi everyone,

 

I was wondering if that would be something that we could put into 3.10?

 

I also get quite a few complaints that the success-page of uninstall is

a bit puzzling...

 

Best regards,

Tobias

 


Von: Hoover, Jacob [[hidden email]]
Gesendet: Donnerstag, 8. Mai 2014 22:18
Bis: WiX toolset developer mailing list
Betreff: Re: [WiX-devs] WIXFEAT:4149 - Add UninstallSuccess page to WixStdBA

If anyone is brave, I have a proof of concept functioning for controls within a page with conditional  Content. (You’ll have to customize your theme to test it, and it only works on the controls within the page - not the application controls.)

 

https://github.com/jchoover/wix3/tree/WIXFEAT4149

 

 

 

From: Neil Sleightholm [[hidden email]]
Sent: Thursday, May 08, 2014 11:03 AM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] WIXFEAT:4149 - Add UninstallSuccess page to WixStdBA

 

+1 for <Content/> I can see that being useful in other places too.

 

Neil

 

From: Hoover, Jacob [[hidden email]]
Sent: 08 May 2014 15:38
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] WIXFEAT:4149 - Add UninstallSuccess page to WixStdBA

 

Could this be as simple as supporting a Visible/Enabled attribute on Text/Hypertext elements? We could then evaluate the attribute when changing pages, and the attribute could contain references to burn variables.

 

Another option (that I really like) would be to introduce a <Content /> element that could be a child of the Text/Button controls and could support a condition on it.  Ex:

    <Page Name="Success">

        <Text X="11" Y="80" Width="-11" Height="30" FontId="2" DisablePrefix="yes">

                 <Content Condition=”WixBundleAction = 2”>#(loc.LayoutSuccessHeader)</Content>

                 <Content Condition=”WixBundleAction = 3”>#(loc.UninstallSuccessHeader)</Content>

                 <Content Condition=”WixBundleAction = 5”>#(loc.ModifySuccessHeader)</Content>

                 <Content Condition=”WixBundleAction = 6”>#(loc.RepairSuccessHeader)</Content>

                 <Content>#(loc.SuccessHeader)</Content>

         </Text>

 

 

Jacob

From: Neil Sleightholm [[hidden email]]
Sent: Thursday, May 08, 2014 1:40 AM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] WIXFEAT:4149 - Add UninstallSuccess page to WixStdBA

 

>> so saying "Setup Successful" after uninstall is confusing to most people. 

 

+1 – I get lots of complaints about this, IMO is makes no sense.

 

Neil

 

    Bob: I'm also convinced that uninstall isn't *that* special.

Well, I guess I can try to convince you :) It's special because if you want to say anything more than "Success" and "Restart Required", it's impossible to have it make sense after an install and an uninstall.  I would say that only setup developers think of "Setup" including install, modify, repair, and uninstall so saying "Setup Successful" after uninstall is confusing to most people.  The default restart message for the Success page is "You must restart your computer before you can use the software.", which is just wrong for uninstall.

 

    Rob: Isn’t there only one success and error page in an MSI? 

 

Didn't I see a discussion with you and Neil about being able to improve on 90's UI? :)  If we don't add pages, then ThmViewer is going to have to be updated to let you modify the environment so that you can do something about all of the overlapping controls.

 

    Rob: I think something like what Heath said below with conditions to hide/show controls plus the ability to have text resolve variables...

 

It's starting to sound like this is definitely the way to go.

 

    Rob: It may be that we finally need to move the condition and variable system out of Burn and into dutil (so thmutil could access it easily), but that’s something I’ve proposed before. Or maybe thmutil can do it all with callbacks (i.e. please evaluate this string as true or false for me).

 

I don't think moving it into dutil is a bad idea, but I don't see what that gets you here.  Since the engine is the one that has the values for all the variables, thmutil will have to depend on callbacks (or a COM interface, or ...).

 

I don't have time to work on this big of a feature for 3.9, I'm more interested in getting 3249 and 4161 in there.


------------------------------------------------------------------------------

_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
12