Bugs item #1841842, was opened at 2007-11-30 17:19 Message generated for change (Comment added) made by barnson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=642714&aid=1841842&group_id=105970
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: wixui Group: v3.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Eric Bickle (shadowchaser) Assigned to: Bob Arnson (barnson) Summary: Move InstallUISequence items out of dialogs and into UIs Initial Comment: Presently, some dialog sequencing information is stored within the dialogs themselves. For example, WelcomeEulaDialog.wxs includes the following: <InstallUISequence> <Show Dialog="WelcomeEulaDlg" Before="ProgressDlg">NOT Installed</Show> </InstallUISequence> Including this information in the dialog file makes it difficult to fully control the sequencing of dialogs in a "custom" ui mode. The dialogs should be fully "self contained", with the sequencing information being 100% contained within the UI files, such as WixUI_FeatureTree.wxs. * Remove all of the InstallUISequence elements from the dialogs and place them as child elements of each individual <UI>. * Remove all of the "Publish" elements from the dialogs that are used to connect sequences of dialogs together. Place the publish elements within each individual "UI" file instead. * Do not include any code within a dialog that looks at "WixUI_Mode". If WixUI_Mode is required in a dialog, it probably means that the dialog is not properly componentized. These changes would componentize each dialog, making them fully reusable in customized user interfaces. ---------------------------------------------------------------------- >Comment By: Bob Arnson (barnson) Date: 2007-12-06 06:35 Message: Logged In: YES user_id=26581 Originator: NO * I hadn't considered wanting to override Cancel. Moving those control events out of the dialogs is +1. * +1 on moving the sequencing out of dialogs that refer to other dialogs, to reduce coupling. * -1 on moving sequencing out of "self-contained" dialogs (e.g., ExitDialog). What we don't have and probably can't given how MSI UI works is the ability to change the sizes or layouts of dialogs or controls. To an extent, the "fix" is to use external UI handlers. Especially with MSI 4.5 supporting embedded external UIs, you get a single .msi package with full UI control, with the cost being more coding. ---------------------------------------------------------------------- Comment By: Eric Bickle (shadowchaser) Date: 2007-12-04 07:31 Message: Logged In: YES user_id=416299 Originator: YES Patches are always welcome. Here's my feedback on your suggestions: 1. Most of the scheduling that exists supports customization. For example, ExitDialog and FatalError schedule themselves but that scheduling is used only if that dialog is referenced. If nothing references the dialog, its scheduling isn't linked in. 1b. That said, the "welcome" dialogs are scheduled before ProgressDlg, so that one dialog is coupled with a couple of others. Two ways come to mind to fix that coupling without losing the "self-scheduling": Use the Overridable attribute or a bind-time variable instead of the literal "ProgressDlg." 2. All the behavior is already moved out of the dialog classes, with the exception of - Installation kickoff - Cancel handling - Print EULA handling I'd argue those shouldn't be overridable in every dialog set (installation kickoff) or are trivial (cancel and print), plus moving those into the dialog set fragments would be a breaking change. I need convincing it's a good idea. It's interesting you brought up cancel handling, since that's one of the cases I was trying to deal with. I've been working on developing an installer that incorporates some of the Vista User Experience Guidelines. Specifically, I removed the "welcome" page and significantly redesigned the "completion" page. In the "Top Guidelines Violations" section, there is an entry titled "Don't confirm commit buttons (including Cancel)" that discusses why it's a bad idea to provide confirmations for cancel events. In WixUI, almost all of the dialogs directly link to CancelDlg, making it extremely difficult to remove that behavior while still being able to re-use and integrate the existing WixUI dialog sets. Although the implementation is more than adequate for the WixUI sequences themselves, I believe portions of the design are inconsistent. I found it extremely frustrating as a developer trying to figure out which dialogs where "stand alone" and which dialogs had an effect on overall dialog sequencing. * UI sequences act as the "glue" that tie together dialogs and choose which ones get hooked up * Dialogs primarily contain only visual elements or actions that are "self-contained" within the dialog (print eula, costing, etc) * Developers who want to create custom UI sequences can create a brand new sequence or base theirs off of one of WixUI's existing sequences. All of the dialogs would be easily interchangeable, including the cancel dialog. * Wix could potentially support dialogs with alternate UIs that wouldn't specifically need to be part of a pre-canned WixUi sequence. Conceptually I like the idea of certain dialogs "hooking themselves up (ie/ UserExit) but it still mixes design with sequencing. Thanks again for taking the time to respond to my comments! ---------------------------------------------------------------------- Comment By: Bob Arnson (barnson) Date: 2007-12-03 21:15 Message: Logged In: YES user_id=26581 Originator: NO Patches are always welcome. Here's my feedback on your suggestions: 1. Most of the scheduling that exists supports customization. For example, ExitDialog and FatalError schedule themselves but that scheduling is used only if that dialog is referenced. If nothing references the dialog, its scheduling isn't linked in. 1b. That said, the "welcome" dialogs are scheduled before ProgressDlg, so that one dialog is coupled with a couple of others. Two ways come to mind to fix that coupling without losing the "self-scheduling": Use the Overridable attribute or a bind-time variable instead of the literal "ProgressDlg." 2. All the behavior is already moved out of the dialog classes, with the exception of - Installation kickoff - Cancel handling - Print EULA handling I'd argue those shouldn't be overridable in every dialog set (installation kickoff) or are trivial (cancel and print), plus moving those into the dialog set fragments would be a breaking change. I need convincing it's a good idea. 3. Nothing looks at WixUI_Mode any more. It's vestigial except that the Dark decompiler looks at it to determine which dialog set was used. ---------------------------------------------------------------------- Comment By: Eric Bickle (shadowchaser) Date: 2007-12-03 18:02 Message: Logged In: YES user_id=416299 Originator: YES I'd be interested in working on this and submitting a patch for this, if the WiX team thinks this is a good idea. Right now, any minor change to any of the dialogs means a developer basically needs to re-write all of the dialogs from scratch to workaround the sequencing/dialog componentization issues. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=642714&aid=1841842&group_id=105970 ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ WiX-devs mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wix-devs
