Avoiding the final setup.exe page
Warren Young
warren@etr-usa.com
Mon Sep 21 18:03:00 GMT 2009
The first problem with the current behavior is that it's brittle in the
face of customization. If I rename, move, or delete a Cygwin icon,
setup.exe thinks it should be helpful and create one for me. setup.exe
requires education, so that it will come to realize that maybe the human
is not an idiot, that the human renamed, moved, or deleted the icon ON
PURPOSE. :)
The second problem is that there are too many icons. I usually get 4:
- Desktop/Cygwin, bash via cmd
- Start/Cygwin/Cygwin, bash via cmd
- Start/Cygwin/MinTTY, bash via MinTTY
- Start/Cygwin-X/XWin, bash via xterm
There may be others created by programs I don't use, such as rxvt.
Some are clear alternatives, with only one used on any given system.
For instance, I believe most people want a Desktop OR Start Menu icon,
not both. Also, if you've installed an alternative terminal program,
such as MinTTY, I believe most people want it to replace the default
cmd.exe based shell icon.
The first two icons in the list above are under control of setup.exe's
current checkboxes, but the latter two get re-created any time the
package gets updated. This is currently not setup.exe's fault, but
since we're talking about refining icon creation, let's make setup.exe
take responsibility for *all* icon creation, so we get consistent, more
intelligent behavior.
I suggest adding a tag to setup.hint whose value is an icon title, to be
used by setup-1.7.exe only. When given, it requests that setup.exe
offer to create an icon for that program.
Here's the logic:
- For each installed package, check for the icon-creation hint.
- If given, add the icon title to a list, for use later.
- If the program is in the Shells group, also set a flag to
suppress offer to create cmd.exe based icons.
- After the postinstalls run, build "Setup Completed" dialog.
My above-listed case would give this:
* Create icons in the Start menu
o Create icons on the desktop
o Create icons in both places
o Don't create icons
[x] Create MinTTY icon
[x] Create XWin icon
(* is a selected radio button, o is a deselected radio button, [x] is a
checked box, [ ] is unchecked, and [-] is unchecked and disabled.)
- On Next:
- For each installed program requesting an icon, set a flag in
the registry indicating that we offered to create it, so we
don't enable the checkbox on subsequent setup.exe runs.
- For each flag, seek and destroy any found icons.
- For each checked box, create the associated icon in the
requested location(s).
- Store the requested icon creation location in the registry
(Non-obvious side effect of above: we now get icon removal on
removing the associated program during subsequent runs.)
- For a simple update-only setup.exe run, you get this instead:
o Create icons in the Start menu
o Create icons on the desktop
o Create icons in both places
* Don't create icons
[-] Create MinTTY icon
[-] Create XWin icon
That is, setup.exe sees that it already offered to create all
possible icons, so it sets the last radio button, disabling
the checkboxes. If one wants one of these icons re-created,
one can set the radio group to the desired creation location
and check the box for that program's icon.
- On adding a package requesting an icon, you get this instead:
* Create icons in the Start menu
o Create icons on the desktop
o Create icons in both places
o Don't create icons
[ ] Create MinTTY icon
[x] Create rxvt icon
[ ] Create XWin icon
As above, the boxes for the two icons it previously offered to
create are unchecked, but one newly added program, rxvt, also
wants an icon, so its box is checked and the radio button
for the previous icon creation location is enabled, thereby
enabling all the checkboxes.
The four radio buttons are always present, as is at least one checkbox.
In the defaults-only case, that would be "Create Cygwin icon", being
the standard bash-via-cmd case. The dialog creation code will have to
be able to resize the dialog box to show more checkboxes if there are
multiple programs requesting icon creation.
More information about the Cygwin-apps
mailing list