On Wed, Mar 23, 2005 at 10:47:26AM -0500, Nathan Carter wrote:
> >> Does your problem lend itself to this sort of a solution? If not, can you
> >> tell us a bit more about it?
> > i don't think i can use such a solution... my problem is that i have
> > to draw a graph on this QCanvas, each node may have multiple fathers
> > and multiple children the recursive procedure is to compute the exact
> > position of each node in the graph based on its ancestors positions
> Can you not choose the number of nodes as the number of progressbar steps?
> >> Perhaps you can come up with an approximation of the number of steps in
> >> your
> >> solution ahead of time? Or recursively subdivide the progressbar at each
> >> point in your recursion tree?
> > that may be the only feasible solution... but again... how can i
> > determine the percentage of job to do? if i have to backtrack because
> > last node position is unacceptable i would have to get back to say 10%
> > while i was at 90% or something... that would be awkward wouldn't it?
> Hmm...I guess you can't choose the number of nodes then. Do you know for
> sure that your algorithm terminates? Why don't you then make the
> progressbar have a length proportional to the worst-case situation of your
> algorithm, and then the user is greeted with pleasant surprises (big leaps
> on the bar) when you DON'T need to backtrack? E.g. if you need to traverse
> each node at most 5 times, then let the size of the progressbar start out at
> 5*numnodes. If you don't have some upper bound like this, then can you be
> sure the algorithm always terminates?
Or use a regular progress bar and unwind it when you backtrack... it
gives the user the idea the machine's not hung, and they get an
indication of how close the thing is to complete...
Not perfect, but not all that terrible, either.
List archive and information: http://lists.trolltech.com/qt-interest/