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. 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 :)