Am Mon, 8 Apr 2019 16:02:10 +0000 schrieb "Murphy, Sean" <smur...@walbro.com>:
> > I would just show one progress set to 3 * raw count. Each stage
> > periodically signals to the ui thread its progress, and whether it has
> > processed the end-of-data signal from the previous stage. In the ui
> > thread slot:
> >
> > int totalCount, rawCount;
> >
> > QVector<int> stageProgress;
> >
> > void stageProgressSlot(int stageIndex, int count, bool completed) {
> >
> > Q_ASSERT(count <= rawCount);
> >
> > auto thisCount = (if completed ? rawCount : count);
> >
> > Q_ASSERT(thisCount >= stageProgress[stageIndex]);
> >
> > totalCount += thisCount - stageProgress[stageIndex];
> >
> > stageProgress[stageIndex] = thisCount;
> >
> > ui->progress->setValue(totalCount);
> >
> > }
> >
> > It will always appear to start slowly then jump forward depending on the
> > degree of filtering. I can't see a way to avoid that other than Bill's
> > idea.
> >
> > Hope that helps, Tony
>
> I think it does, thank you. I can't really see any other way to do it to
> provide a somewhat meaningful progress bar - I'd like to avoid the
> "busy" progress bar if possible since that doesn't offer the user any sort
> of sense of how much longer they have to wait and your idea at least
> gives them some sense of status, even if it's not 100% accurate at all times.
>
> Sean
what about 2 progress bars? one for the count of filter processes, and the
other for the steps at each process?
i use this when loading several files (your filter processes) and display the
current line in a file (your steps).
--
/*
*printk(KERN_ERR "Danger Will Robinson: failed to re-trigger IRQ%d\n", irq);
* linux-2.6.6/arch/arm/common/sa1111.c
*/
pgpK1HwGeq1gQ.pgp
Description: Digitale Signatur von OpenPGP
_______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
