On Thu, 2006-11-30 at 22:45 -0800, Toshio Kuratomi wrote: > On Thu, 2006-11-30 at 21:21 -0500, Jeremy Katz wrote: > > On Thu, 2006-11-30 at 09:29 -0800, Toshio Kuratomi wrote: > > > 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. > > You are talking about what you wanted from the installer. But that's > not necessarily relevant to what you want from a graphical package > manager. Or from a web based package lister (a la repoview). repoview > doesn't need to worry about multiple selection of packages, for > instance. This confirms my suspicion that we're talking past each other :-) But yes, different interfaces want different metadata. The crux of my argument is that "comps.xml" isn't the metadata for that purpose. And with repomd, we now have the ability to drop in arbitrary metadata and they only get fetched by the tools trying to use them. Trying to make it so that we handle every possible use case with one file just isn't going to work, IMHO. So yes, for a web based package tool (son of repoview), there are different sorts of things you're going to want. To be Web 2.0-y, you probably want arbitrary tagging of packages, linking between tags, etc. And that's _awesome_ for a web presentation. It sucks rocks for a native UI. > > > 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. > > search and browse are very different. I would say that browse is at > least as useful to get right as search, possibly more. Search works on > the principle that you know what you are looking for, you just don't > know its name. Browse works on the principle that you sense what you > are looking for, you just don't know how to express what that is. When looking for software, which do you do first? a) Go to google, put in some keywords, search b) Go to freshmeat/sourceforge and browse through their "troves" Or for a non-software analogy, how do you find stuff at Amazon? Do you search or do you go through the stores and walk through the long lists of stuff? While I used to "browse", the amount of stuff is just too overwhelming now and I almost always search for something and then use the "related items" to go explore more. Jeremy -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
