Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: Comments on Robert's category feature
content-class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0
Date: Mon, 18 Jun 2001 12:38:51 +1000
Message-ID: <EA18B9FA0FE4194AA2B4CDB91F73C0EF7A05@itdomain002.itdomain.net.au>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Comments on Robert's category feature
Thread-Index: AcD3nrSFU0c0Bxv6RPKSYpqeDPL1cwAADVeQ
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: <cygwin-developers AT cygwin DOT com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id WAA17002

> -----Original Message-----
> From: Christopher Faylor [mailto:cgf AT redhat DOT com]
> I think that if we have a few categories:
> 
> Default (or Core?)
> Standard
> Development
> Graphics
> XFree86
> 
> It might help.

Definately. One problem with my current code is that non-default stuff
doesn't show unless full/part is clicked. Thats what I was referring to.
 
> 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.

I'm confused here :].

Are you saying that
category foo (clickable to expand/contract)
  package-in-current-format
  package-in-current-format

is good or bad? I think that would be quite nice to use.
 
> 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'll leave that side of it to you :].
 
> I know that we have an infinite amount of stuff to do but I just
> want to get to the next level.

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

Win32ness of the GUI doesn't have to be coupled with win32ness of the
algorithm or file formats :] By which I mean that we can still leverage
bit by bit. Even if we don't reuse, we can learn from them.

Rob
 
> cgf
>