Hi, here is my promised prototype for a new progress dialog behaviour. It implements the Gnome HIG recommendations for external feedback: * It comes up 1 sec after the operation started * leaves the dialog onscreen 1 sec after the operation finishes (currently it stays for at least 1 sec after creation) * provides a reassuring message about the outcome of its associated transfer (Completed/Aborted/Error) * replaces the cancel button with an ok button at this point * pressing ok closes the dialog immediatly, so does cancel before * the dialog immediatly gets shown if a request related to the transfer comes up (avoids a clueless dialog poping up delayed behind a requester) * however, the dialog tries to avoid to get onscreen if there's no progress to report yet (this works around a lame progress dialog coming up if the transfer is immediatly aborted, without actually transfering anything). It then reschedules for another second. Everyone who dares to give it a try (it should cleanly apply to 1.0.6 & nautilus-gnome-1), please report strange behaviour to me and if it "feels right" for you. There's still the issue of not providing immediate feedback on transfers with this version. I for one would love to see the throbber spin when a operation is in progress (up to the point where the feedback is provided by the dialog). Currently throbber activity is only wired to "location-change" (= directory change in the context of file management). It should spin more often - It's underused and cute :p Please note that you can't try to supress the progress dialog even when the dialog is at 99% at the unhide checkpoint, because you can't assume that the remaining 1% will only take 1/100 of the total transfer time. Some comments on the implementation: (Darin, please speak up if I'm talking bs) I tried to contain the when-to-show logic in the Dialog itself and not clutter the various callbacks throughout file operations. So the progress dialog now uses a callback to notify the transfer on cancel - This is basically all you want to know about your dialog as transfer. It establishes proper bounds for the signal handling of the widget, the way it works now is only to get access to the cancelled flag of the transfer on user response (but causes the destruction sequence to be a bit confusing - this is the root of the dialog crashing bug). You currently can't work around the complicated behaviour in regard to request dialogs because the dialog does not really know how long a transfer has spend _actively_ transfering data. A conflict during execution pauses it until the user responds. You'd have to expose the timer of the dialog to the outside and make the blocking request stop it when it's up or extend the progress_info structure of gnomevfs to include more extensive info. However, in practice this approach seems to work reasonably well. I'm not sure if I completly understand how this is supposed to work, but there seem to be multiple bugs in gnome-vfs regarding the update of progress_info (some elements get overwritten and/or are not updated). It also has the concept of "default overhead": a constant which represents the size of transfer items with no inherent size. This is hairy to begin with because the distinctionbetween the amount of data that was transfered and the amount of progress this represents is blurred. You can't make a progress_info user use item count to configure the progress bar when you encounter total 0 bytes operations for example, because there are no such operations when "fake" bytes are added to everything. If gnome-vfs wants to provide recommendations about how the progress should be represented it should supply a percentage value imho. But there's also a bug in the implementation of it: There's a case where it doesn't add the overhead to bytes_copied during the transfer. So you can't rely on testing bytes_copied if you want to know if "there's progress to report". This is the way the current widget works and accounts for at least one bugzilla bug about it. Funny enough, at the end I found - deep down in gnomevfs - the same assumption I wanted to get rid off in the first place: moves on the same filesystem are so fast that you don't bother to create a recursive filecount (see bug#46777). It actually does the right test on move around there (all files on same_fs?), but in a way that looks a bit suspicious. I'll comment on gnome-vfs list when I spent more thought on it. I commented quite a bit to make it easier to review, but there are auto-extended-spaces instead of tabs in the patch, beware. I also didn't spend as much time testing all possible cases as i should have. I'd come up with a more polished version if someone actually wants to use it. (And I could extract the pure bugfixes from this version if anyone is interested in them, but these issues all depend on each other) Have fun with it, Martin
Attachment:
progress-patch.diff.gz
Description: GNU Zip compressed data