This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Avoiding the final setup.exe page


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]