On Thu, 2006-11-30 at 09:29 -0800, Toshio Kuratomi wrote: > On Thu, 2006-11-30 at 10:52 -0500, Jeremy Katz wrote: > > The "problem" is that if you do something like this, you _really_ don't > > want to be using the current UI. > > There's an assumption here of what the current UI is. From your > background and the background of comps I would assume that "current UI" > means anaconda's interface. However, comps.xml has been proposed as a > replacement for the rpm group tag in general. Repoview already attempts > to do this (with a horrible number of entries in the uncategorized > listing). apt/synaptic and smart currently use the rpm group tag and it > was proposed that they should be ported to use comps instead of > rpm::group. I would say that apt and smart's UI would not suffer from a > migration to comps provided that comps lists all the packages in the > repository. And that _used_ to be anaconda's UI and anaconda used the group tag. That was changed so that: a) the grouping information could be changed by third parties without requiring the packages to be rebuilt b) browsing through every package in the distribution wasn't interesting when it was < 1000. browsing through 4000 packages is even worse > > Rather than focusing on the question > > of "how do I fit this in comps" or "how do I list every package because > > oh my god, how else do I find something", the _real_ question is trying > > to figure out what the user experience we're trying to get at is, get > > some mock ups and then figure out what the "right" implementation path > > is from there. > > > User Experience > Objective > Allow a user to view a subset of packages in a set of repositories > that matches categories of software that they are interested in > installing. This allows the user to more quickly discover a package > that fills a need for them. While a good high level description of what's wanted, it's not a very good place to start for designing a UI. Things really need to be far more focused. Use cases are one common approach; there are others. > Interface1 > 1) Select a group from all groups valid for the repository > 2) List all packages which match that group. > 3) Allow the user to select another group from the groups that these > packages have. > Repeat from 2 until A) the list of other groups would have a single > entry, B) there's only a single package in the package list. C) User has > left this interface This is actually a direction that we (pnasrat, clumens, myself and a few others) were looking at when we got to the current package selection UI. The problems started coming in around how to sanely handle a native UI where you want to allow multiple selection of packages, and then viewing even more details without too many levels of nested dialogs. > Interface2 > yum groupsearch Development Python Cryptography > Finds all packages in the repositories whose group information > contains all of those patterns. Search is *definitely* something that's incredibly useful and important. Realistically, it's probably more interesting than browse for most use cases. Can the search that's currently there be improved, yep. Was easiest to just start with 'yum search' and then improve from there. Jeremy -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
