Avoiding the final setup.exe page
Mon Sep 21 21:50:00 GMT 2009
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
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
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
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.
More information about the Cygwin-apps