JR, IIRC, last time we discussed this I asked if we could simply count the number of file downloaded and remaining, and why that wouldn't be sufficient.
A related comment concerning src/gui/modules/filelist.py in the webrev you just published: I wouldn't override _extract_files() or other methods that are internal to the operation of filelist. I've been actively making changes in this part of the client code, and it's likely that they'll end up breaking your changes. It would be easier to figure out what you're trying to accomplish and then add a set of routines that you can override in the gui module, if necessary. I'd like to avoid duplicated code in the GUI for file extraction. -j On Thu, Jul 31, 2008 at 07:37:41PM +0100, jmr wrote: > J - the idea was that we could still show the progress details as > listing of files, even if some where cached. What is currently in the > 2008.05 IPS GUI in the details panel is that the first file in the hash > is listed. I had assumed that this is what Synaptic did when looking at > some screen shots, which refer to: "Show progress for single files" and > had erroneously assumed this was package files as opposed to the > package, my mistake :( They are doing it in the Details on a per package > progress indicator. > > So if we got chunk size progress notification per package then we should > have enough to display progress for each package in a smooth fashion as > opposed to the very jerky manner we have to do currently where progress > notifications are raised for a package after each file download has > completed, as opposed to a given chunk size. In the Progress Tracker > though we'd need the actual amount of data that needs to be downloaded > for the package, not just the total package size, given some files may > already be cached on the system, to setup any progress indicators > appropriately. > > JR > > > [EMAIL PROTECTED] wrote: > >> 2. Provide Progress by Filename. There has been some discussion about > >> this. > >> We would propose feeding back to the ProgressTracker a FileList for each > >> hash that is being downloaded and then its up to the client to decide how > >> to display these multiple files for the single download object. > >> > > > > Given that we've already had a discussion about how tracking downloads > > by filename doesn't make any sense, I'm surprised to see it here again. > > > > The download is retrieving a file based upon its content, not its > > destination path in the filesystem. We cache downloaded files, so if > > /etc/X11/foo.conf, /usr/X11/foo.conf, and /var/cache/foo.conf all have > > the same content, we will download > > da39a3ee5e6b4b0d3255bfef95601890afd80709, but only once. > > > > -j > > > > _______________________________________________ > pkg-discuss mailing list > [email protected] > http://mail.opensolaris.org/mailman/listinfo/pkg-discuss _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
