> > My sense is that most Windows users really _don't_ care too much about
> > this, but I believe it's important enough to put in for sake of
> > "rightness" and for the users who actually do care.
> 
> I'm getting lost again.  What is it that Windows users care or not
> care about? :)

Valid, interesting question.

Should we try to define different "target profiles" or "user roles"?


1) Ruby coders:  IMHO, don't really need gui except for complex
installations, such as the case of the OneClickInstaller, that
prepares a full-blown workbench. Most experienced coders I know prefer
control instead of colours and whistles. (hey, they may want the
whistles if they can still be in control).  Now, I personally believe
complexity can be encapsulated and hidden to some degree, but it must
always be accessible, and that goes for new ruby programmers too.
GUI installer examples from the extra-ruby world:   the Tomcat
installer, the Java webstart installer, etc.
BUT:  when you need to deploy applications INTO Tomcat, you don
normally use an installer, unless it's a really big thing and mission
critical that could also be prepackaged with Tomcat included.

When a developer uses an installer, becomes a user type 2:  GUI user
setting up a full blown application.

When a developer installs a new library, module, extension, etc.
he/she is a user type #1:  developer at work


2) Final user of Applications written in Ruby:  here GUIs and
installers are the rule, not the exception,  installation should be
seamlessly integrated with the default package management tool for the
host system (in case there one available)
ie:  rpm for redhat,  dmg for MacOsX,  żż msi for windows ??
(really, what does "package management" mean in the Windows world ?)
A Ruby application shouldn't feel any different from one written in
another language in the same host system.
That includes setting the right registry entries, setting up, starting
and stopping system services,  etc.
The Unix version of this would be writing configs to /etc,  and
managing the SysV init system.  (there might be slight variations of
this for different Linux distros and Unices)


3) Packagers:  don't really need a GUI, except for tools that ease the
task to browse through categories of packages, perhaps task automation
for the building process and other niceties will come later.  Still
all the GUI should ideally run as an alternative frontend, the
underlaying engine should be in place first and not directly tied to
any user interface.

The OneClickInstallers seem to be addressing a series of needs from
each of these roles.
I understand Curt's concern and it's a wise decision to present
optional packages as a category tree,  I just think the installer in
this case should unify the criteria and be either an installer or a
gui frontend to a package manager,  mantaining both can be a
nightmare.

that's all I can think of from the top of my head, there's probably
room for improvement



-- 
--- vruz