[PATCH] Setup Chooser integration

Gary R Van Sickle tiberius@braemarinc.com
Tue Apr 2 13:13:00 GMT 2002

> Gary, I haven't reviewed this yet...
> Can we, with the patch as is, do the following:
> Pop up a chooser?

If you're asking if there's still a do_choose(), the answer is no.  Does the
patch preclude such functionality?  No, but it would require additional

> That's it. Nice and simple eh? Well, once I've got the 
> collection based
> PickView together, then that should be all there is to it.
> What is this in aid of?
> Image: you click on 'install' for 'gcc', and up pops a window 
> that lists
> everything that gcc depends on (both requires as we have today, and
> 'suggested' items that aren't always needed but are useful - ie
> autoconf), that was not selected before that click. 

I'm drawing a blank at the utility of such a feature, at least in the guise
of a popup of any kind.  You're saying that as you go through the dozens of
packages you want and select them, that a box pops up bugging you about the
dependencies of each selection, which you can't do anything about anyways?
That sounds like it would be extremely irritating.

As for suggestions, mixing them in with dependencies sounds bad to me.
Don't the metapackages/"Wokstation/Sever/etc" ideas, however they end up
working out, handle suggested packages adequately?

> Likewise, if you click ash off, up pops a window listing 
> everything that
> depends on ash, with an addiotnal message of "Warning: 
> removing ash will
> cause these packages to be removed as well.

This does make quite a bit of sense to me.  But wouldn't MessageBox() or
something akin to it be a better fit to the task?  The only possible user
input here would be "Yes, remove ash and everything dependent on it" and
"Cancel", and the only output a list of package names.

> So what I'm asking you now, is if your patch to the chooser 
> will work in
> with this long term plan, or are they orthogonal, or is it a step
> backwards?

As I see it, all three:

- The long-term plan has to have at least the primary chooser integrated
into the Wizard.  This patch puts that one to bed.
- The changes required to fully implement what you've outlined above are
largely orthogonal to the relatively minor changes in this patch.
- There's no do_choose() exported anymore, so in that sense you could call
it a step back.  (You could, I wouldn't ;-)).

> I guess we could replace the view in-place within the setup window -
> maybe that would be better and cleaner? (Noting that the 
> PickView class
> is heading to be a win32 window with reflector inheriting from your
> Window class, so we need some way of removing/hiding the saved window
> and then restoring it...)

Microsoft's own installers (e.g. Office) seem to work that way IIRC.  Then
again I've never been real crazy about their installers - things that seem
like they should be "tree-like" aren't (e.g. selecting sub-elements of a
package), and things are presented in tree-fashion that don't seem like they
should be (selecting the "install/install on demand/don't install").

> Anyway, is this clear as mud?

Hey, if this stuff was easy, anybody could do it. ;-)

> Rob

Gary R. Van Sickle
Braemar Inc.
11481 Rupp Dr.
Burnsville, MN 55337
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 3476 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin-patches/attachments/20020402/024b6288/attachment.bin>

More information about the Cygwin-patches mailing list