RE: Comments on Robert's category feature

["Robert Collins" <robert dot collins at itdomain dot com dot au>]

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