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


On Mon, Jun 18, 2001 at 12:13:10PM +1000, Robert Collins wrote:
>>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").

I think that if we have a few categories:

Default (or Core?)
Standard
Development
Graphics
XFree86

It might help.

With those, we should be able to get by for now.  I just don't like the
grouping of Category on the side.  I think that people will be confused
by it so I don't think that it is a good first cut at what needs to be
done.

Also, as a side effect of getting some of this info into setup.ini, we
could construct a web page that people could inspect to find out what's
what.  Also, we could use DJ's tar file browser to allow people to find
files and we could set up a search facility that would allow people to
search tar files a la rpmfind.net.

I know that we have an infinite amount of stuff to do but I just
want to get to the next level.

>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.

Simplicity of the GUI doesn't have to be coupled with simplicity of the
dependency algorithm, though.  We can still display collapsing/expanding
categories in your current scheme.

I am going to be going away this week again.  I'll try to use my flight
times to come up with a proof of concept.

>I think the full/part button should be renamed to "view" and cycle
>between - full/part/categories.  That should be fairly intuitive.

Sounds ok.

I know that we are reinventing the wheel here and that is bad but I'm
not 100% convinced that using RPM or PKG is really the way to go here.
Maybe it's just because I don't currently know how to use their
interfaces or maybe I'm just not looking forward to making the interface
completely win32.

cgf


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