This is the mail archive of the
cygwin-developers@cygwin.com
mailing list for the Cygwin project.
RE: Comments on Robert's category feature
- To: <cygwin-developers at cygwin dot com>
- Subject: RE: Comments on Robert's category feature
- From: "Robert Collins" <robert dot collins at itdomain dot com dot au>
- Date: Mon, 18 Jun 2001 12:38:51 +1000
> -----Original Message-----
> From: Christopher Faylor [mailto:cgf@redhat.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
>