Avoiding the final setup.exe page

[Warren Young]

Charles Wilson wrote:
> 
>> I suggest adding a tag to setup.hint whose value is an icon title
> 
> #1. WAY too simplistic.

For some cases, sure.  It suffices for many others, though, probably 
even most others.  If you want to add more tags to the design, fine, but 
for v1.0, these other options should just assume reasonable defaults.

> How can I specify...the .ico to use (or .dll + iconoffset), etc?

The default is to not specify an icon, in which case you get the .exe's 
default icon.

At least at first, I'd rather see effort go into adding a resource 
section to the .exe with the desired icon in the first position, rather 
than extending setup.exe to let you pick alternate icons.

You might need such a mechanism for a DLL run via a shortcut through 
rundll32.exe (or similar), but does that actually happen with any 
current packages?

My proposal might have looked like a lot of functionality, but really it 
was just a thorough explanation of the various states that the new 
functionality allows.  I am not trying to solve 100% of all possible 
problems with the first design, nor should attempting to do so be a 
reason not to start down this path.  We may eventually achieve this 100% 
solution, but we don't have to have it to make the first 10% useful.

> And...how can I set up two or more shortcuts for a given package (e.g.
> rxvt-unicode would have at least two: the "standalone" urxvt, and the
> "daemon client" urxvtc one -- never mind trying to start the urxvtd
> daemon itself via a shortcut).

This is another > 10% thing we don't have to solve today.  We can 
continue to let postinstall scripts handle the complex cases.  As 
setup.exe gets more capable, we can replace more postinstall code with 
setup.ini hints.

> SMTC

I don't see that in the acronym list.  Is it like SHTDI?

> show me an estimate of how much new code, how many new classes, and how
> much modification to existing code your proposal will require.

I spent over an hour composing my proposal, carefully thinking through 
and listing all the cases.  It's standard software engineering technique 
to take the use case list at the end of that message into whatever 
formal design methodology you like.  This mapping should be done by the 
person who will implement it.  If that person is me, I don't need to 
give detailed design here, and if it's someone else, they don't need to 
show it here, either.  Just look through the proposal and see if it is 
a) useful and b) implementable.  Then all that's wanted is an 
implementor, because we'll have a good, vetted design.

If you think I've left something unexplained, or explained it poorly, by 
all means, ask me about it.