On Sun, 2008-09-21 at 21:33 +0000, Kevin Kofler wrote: > As you'll certainly ask me why, i.e. what's wrong with the current > implementation, here's it: With the current UI: > * there is no way to see what's in the collection, You get prompted with the full list when you try and install. You can use Get Dependencies on the collection if you want to know beforehand. > * it is inconsistent: both the comps.xml groups and the hardcoded categories > are lists of packages The hardcoded groups are not lists of packages, it's a map of comps groups to PK groups. > IMHO, a much better approach would be to: > * throw out the hardcoded categories! We have that information in comps.xml, > PackageKit should not try to duplicate it. It's not. Groups are a subset of the comps groups. I've done substantial user research, and I'm sorry to say fine grained categories _do not work_ with real users. None of the people in http://www.packagekit.org/pk-profiles.html could tell me what they expected to find in base-system/system-tools or base-system/admin-tools, or tell me the difference between them. > * add tristate checkboxes next to the groups, like in Anaconda: by default, > they're in the gray state, unless you have all packages installed (checked) or > none (unchecked); they can be checked or unchecked, which is equivalent to a > groupinstall or groupremove, but the only way to get them into the gray state > is to individually install or remove packages from the group (using the list > view on the right). That would be a usability disaster. Do you want to try explaining how a tristate checkbox works to any of the people on the profiles page? Richard. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
