On 17 August 2017 at 12:41, Stefan Tauner stefan.tauner@gmx.at wrote:
If we want to make the life of the caller easier and notify it of these events we should not use the "enum flashrom_progress_stage" parameter for it or rename it. I'd rather separate these two things completely like this: enum flashrom_progress_stage { enum flashrom_progress_event {
Looks sane to me.
FLASHROM_PROGEV_SKIP_{STEP, STAGE}, /* If and when we skip a step, or possibly even stage */Is this useful at all?
I don't think showing the skip is super useful.
The disadvantage is that this is completely non-linear speed and there need to exist prior knowledge in the caller.
This is something I tried to do with libhif: https://github.com/rpm-software-management/libdnf/blob/master/libdnf/dnf-sta... -- and it gets really hard, really fast. I think linear speed is a nice thing to have, but don't bust a kidney over it. Remember at the moment I've screen-scraping addresses...
- Go fully berserk and add another callback that informs the application of the overall plan/layout of stages flashrom will do.
Or maybe in the progress callback just have ints for the number of stages to complete and the number of states that are completed. If the UI wants global then it can do the simple math to make it one value, otherwise it just ignores the stages.
Richard
-
Richard Hughes