On Fri, 2005-11-25 at 10:54 +0100, Joachim Frieben wrote: > "up2date-gnome" has a very clear, informative interface. You start with a > channel windows that allows you review the available channels and to make > your choice. Very nice, indeed. Why would you want to not download updates from all repositories you have configured? Or at least see what's available. The fact that the updates come from multiple repositories is a detail that I don't think users really want to / should need to care about. > Once the header information is downloaded, a > concise but exhaustive package list is displayed, which from you obtain all > interesting details like package name, previous version, current version, > channel and so on. Furthermore, it's possible to resize the width of the > individual columns. Even for a significant number of available packages, you > keep an oversight of what is going on. Some of the sizings and spacing still need work with pup, definitely. That's the sort of modifications that are easy to make once the code is working and thus it hasn't been high on my todo list. File bugs and we'll definitely see about getting to them as soon as we can. One thing that's fundamentally different with pup is that we're trying to get away from the package being (necessarily) the point of granularity. The hope is that we can actually get the update information available via the yum metadata so that we can instead provide more useful update information such as -- "New version of apache httpd daemon to fix security vulnerability foo" and then have all of the packages which are a part of that advisory grouped together rather than requiring you to know that you need all of httpd, httpd-devel and mod_ssl as a bunch. Since we don't have that metadata currently available (and never will for the development tree and probably also some other repositories), the fallback is to grouping packages by source RPM. > After confirming the package > selection you proceed to the clear and informative download window. > Individual package download progress and total progress are displayed > together with some info in the package that is currently downloaded. The > same holds for the package installation step. We've been doing some hallway bantering about how to improve the progress dialogs generally for all of anaconda, pup, and system-config-packages as they all have the same basic problem. You both somewhat want to show the progress of each individual file as well as the total progress. I somewhat like the approach taken with nautilus (try scp'ing a few hundred files with it) but want to do some more investigation before committing to anything. I'm sure I've opened it up to the peanut gallery now :-) > I also love the summary at the > very end which lets you have a final look on which packages got upgraded. I've always personally found this to be a bit of a waste and just another click which isn't really needed -- I asked for updates, when they're done, get out of my way :) > And do not forget the neat red/grey coulour scheme :) > "pup" with its greyish look and the strange doggy icon that does everything > but fit the genuine Bluecurve icon style looks like the little, poor bother > of big "up2date-gnome". Yeah, we need some graphic work, but that'll come in time. I don't want to have Diana spending a lot of time on graphics as we tweak things over time. > Its interface is cluttered, the package window only > lets you see some packages at once. Yeah, the sizing needs to be tweaked some. Trivial fixes to the glade file :) > There is little info on the available > updates. In the main window, there is this boring "Updated ... packages > available" message for every single package. I would call this redundancy at > its best. If you want a bit more information you have to expand the "Update > details" window. As I said above, we're planning to actually have actual update information here that's even more useful here. The text is mostly placeholder for now... I'm open to suggestions for how to word in the case where update advisories aren't available, because that will always be a somewhat common occurrence. Cheers, Jeremy -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
