This is the mail archive of the cygwin-developers@cygwin.com 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]

RE: Comments on Robert's category feature


> -----Original Message-----
> From: Christopher Faylor [mailto:cgf@redhat.com]
> Sent: Monday, June 18, 2001 11:10 AM
> To: cygwin-patches@cygwin.com
> Subject: Comments on Robert's category feature
> 
> 
> On Thu, Jun 14, 2001 at 10:53:09PM -0400, Christopher Faylor wrote:
> >On Thu, Jun 14, 2001 at 08:31:49PM -0400, Christopher Faylor wrote:
> >>I'm testing the other stuff in the meantime.
> >
> >I'm still checking but I also checked in the parsing parts 
> of your patch
> >since I think that they are definitely the way to go.
> 
> Ok, I've played with Robert's changes and I don't think that 
> they go far
> enough.  Has anyone else looked at them?

There's plenty more to do. A popup chooser to choose what packages to
use to satisfy dependencies. The ability to lock a package, so that it
doesn't get autoinstalled - say when you have a custom automake on your
system. The question is how much is needed to ensure that a default
install is useable, and that the existence of non-default packages is
easily visible. (So we don't get "I installed cygwin, but cannot find
where it put gcc").

Of those, I think the key one is the visibility of all the non-test
categories/packages by default. 

> I think we still need to change the chooser dialog so that it can
> create different views.  The default view should just display 
> categories.
> Maybe categories should have those nifty chooser things so 
> that you can
> deselect the whole thing, use test versions for the category, download
> sources for the category, skip the category, etc.

At this point I was aiming for a simple-but-does-the-job approach. I
think those nifty things fall into our laps when more of the background
detail is implemented - for example per version dependencies and
"features" provided per package. [De]selecting the category would be
very useful now however.

The reason for keeping it simply was to assuage my only concern : that
we keep it fairly simplistic, until "someone" gets the time to integrate
in the core algorithms from a mature packaging & dependency system.
 
> Clicking on the category name should expand it (maybe we need 
> an icon next
> to the category name to make this clear).  Underneath the 
> category name
> would be the list of everything in the category, in the 
> standard format.
>
> If we were ambitious, we could also have a button at the top 
> which switched
> everything to the "old view" where all packages were displayed.

I think the full/part button should be renamed to "view" and cycle
between - full/part/categories. That should be fairly intuitive.
 
> I don't think that these changes are too huge.  Robert has 
> already laid
> the infrastructure for doing this.
> 
> Does this make any sense?  Comments?

See inline above.
 
> Thanks to Robert for getting the ball rolling with this.

No probs :].
 
> cgf
> 


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