On Dec 3, 2007 4:50 PM, Xavier <shiningxc@gmail.com> wrote:
On Mon, Dec 03, 2007 at 04:29:58PM -0600, Aaron Griffin wrote:
On Dec 3, 2007 4:20 PM, Xavier <shiningxc@gmail.com> wrote:
Since Aaron promised restoring the padding way in 3 lines, I couldn't really compete with that ;), and besides 3.0 already has a sample implementation. So I tried exploring the delayed output way instead, and hacked something together in ~50 lines. It's very ugly and hackish, but it's just meant as a proof of concept, because I'm not even sure the idea is right.
Hah, yeah I actually assumed some sort of vasprintf-esque function, so I would have counted that too.
Still, I think that for the time being a "hackish" solution is best (even though this one is pretty good), because we just need to do some cleanup to get 3.1 out the door.
I like it.
Oh, ok then. Let's see if this "hackish" solution is also good enough for Dan, and then the eventual cleanup / refactoring / renaming that needs to be done, as well as commenting this hack in the code.
For now, this looks quite good enough. Great work. You did this as cleanly as one would possibly be able to- the only other concern would be with a interrupt, which I haven't tested.
I originally tried to base the detection of the progress bar in cb_trans_evt, based on the events sent before and after the progress bar. But there were the different upgrade / add / remove cases to consider, and it looked a bit messy. So I tried to move it at the end of cb_trans_progress, based on the "int percent" argument, and it turned out to be easier, and better factored for the different cases.
Anyway, I wasn't familiar with this part of the code at all, so this hack should be carefully reviewed before being considered to be merged :)
I'm going to let it bake on my working branch tonight (I made a few small changes but nothing huge). If everyone could give it a test that would be great. -Dan