[rar] add a callback class for unrarlib rather than calling into guilib

[jmarshallnz]

We don't want to call into guilib directly from unrarlib, so this does the same as what we were doing (though with a 200ms delay) via a callback class.

@mkortstiege This should be pretty equivalent to what we already have in master. i.e. it is useful as a base from which to make further changes, such as increasing the time before display, or switching to busy dialog etc.

[mkortstiege]

Yep, that will do. Thanks.

[jmarshallnz]

Oh, needs testing ofc - I didn't do any at all :p

[mkortstiege]

OK, will give it a chance around the weekend.

[mkortstiege]

Looks good and works for me, thanks. Not sure if 200 ms is enough for slower hardware though or if we should make it adjustable to get an consistent UX. @popcornmix what's again the timings for rar stuff on the PI?

[popcornmix]

Doesn't seem to calculate percentage correctly.
Tried two files and one pops up "-6%" (yes, negative) and the other "-31%" and the progress bar immediately disappears.

[jmarshallnz]

My bet is it did it before this change as well? Can't see how the percentage is calculated any differently here at least?

[popcornmix]

I was wrong about the negative, I think it's just a "-" used as a separator.

Without this PR the progress bar stays up for many seconds and updates from 0 to 100%.
With this PR the progress bar just flicks up for a fraction of a second.

Looks like this PR makes the rar extraction fail:

11:35:46 55235.421875 T:2901001296   ERROR: filerar::open failed to cache file The.Wolf.of.Wall.Street.2013.720p.BluRay.X264-AMIABLE.sub

Log without this PR: http://paste.ubuntu.com/7784423/
Log with this PR: http://paste.ubuntu.com/7784438/

[mkortstiege]

That's weird. I have no such filerar::open issues here. All external (rarred) subs are detected properly.

[jmarshallnz]

Defaulting to cancel = false is probably the reason for the failures :)

[jmarshallnz]

Updated - should be all good now. @popcornmix mind testing when you have a few?

[popcornmix]

Fails again.
The logic for cancel is inverted.
You fail if:

    if (!m_progress(m_context, int(float(CurUnpWrite)/float(((Archive*)SrcFile)->NewLhd.FullUnpSize)*100), NULL))

But progress returns true if cancelled.

Tested with progress returning "!cancel" and it behaves as desired.

[jmarshallnz]

Ah, I switched the wrong bool. I'll add some doxy about what it's supposed to do then make sure it does it. While paying attention this time :)

[jmarshallnz]

@popcornmix, @mkortstiege updated - pretty confident this time (3rd, 4th times the charm?)

[jmarshallnz]

rebased. jenkins build this please

[mkortstiege]

Works. Jenkins build failure is unrelated.. Android slave has problems as it seems.

[popcornmix]

Looks okay to me.