[squeak-dev] Progress bar design pattern
Martin Dias
tinchodias at gmail.com
Thu Mar 31 21:56:25 UTC 2011
MISPRINT:
In the last part when says:
"The announcement can also know
algorithm
self doA.
self announce: (WorkAnnoucement finished: #doA)."
shouldn't go!
Cheers,
Martin
On Thu, Mar 31, 2011 at 6:53 PM, Martin Dias <tinchodias at gmail.com> wrote:
>
> On Thu, Mar 31, 2011 at 5:47 PM, Yoshiki Ohshima <yoshiki at vpri.org> wrote:
>
>> I don't understand the problem. Let us say we start from the
>> example in the method:
>>
>> --------------------
>> 'Now here''s some Real Progress'
>> displayProgressAt: Sensor cursorPoint
>> from: 0 to: 10
>> during: [:bar |
>> 1 to: 10 do: [:x | bar value: x.
>> (Delay forMilliseconds: 500) wait]].
>> --------------------
>>
>> and your "algorithm" here would be:
>>
>> 1 to: 10 do: [:x | "do something here"
>> (Delay forMilliseconds: 500) wait].
>>
>> It is already reasonably decoupled to me, but I take that you want to
>> keep the "algorithm" really prestine and don't want to have "bar
>> value: x" call in there, and completely get rid of anything from "do
>> something here". Is this the case?
>>
>> There still have to have some way to tell how much percent of work
>> done from the "algorithm" to the progress notification mechanism. In
>> the possible meta approach (which would not be that hard at all), I'd
>> make an instance variable for the object that represents your
>> algorithm state, and the algorithm assigns a value to the instance
>> variable, and the progress bar displayer that is running in a separate
>> thread looks at the variable periodically and update the screen.
>>
>> However, in this senario, you would have to have an assignment to
>> that variable at "do something here":
>>
>> -----------------
>> 1 to: 10 do: [:x | progress := x.
>> (Delay forMilliseconds: 500) wait].
>> -----------------
>>
>> But is "progress := x" any better than "bar value: x"?
>>
>> Somebody suggested announcements. So your algorithm would look like:
>>
>> -----------------
>> 1 to: 10 do: [:x | self announce: (ProgressAnnouncement value: x).
>> (Delay forMilliseconds: 500) wait].
>> -----------------
>>
>> And a stepping morph surely does not work. If something was started
>> from a do-it in workspace, next time the morph gets #step message is
>> after the do-it is completed.
>>
>> The "bar" block could be stored in an instance variable of the
>> algorithm object, and your algorithm may do:
>>
>> -----------------
>> 1 to: 10 do: [:x | bar ifNotNil: [bar value: x].
>> (Delay forMilliseconds: 500) wait].
>> -----------------
>>
>> This may be just as good as it gets without complicating anything
>> else.
>>
>> Note that your algorithm may not be a loop. It is totally legitimate
>> to write:
>>
>> algorithm
>> self doA.
>> bar value: 0.33.
>> self doB.
>> bar value: 0.66.
>> self doC.
>>
>>
> What you sent makes me think...
>
> I am not convinced of this other solution, but with announcements could be:
>
> algorithm
> self doA.
> self announce: (WorkAnnoucement finished: #doA).
> self doB.
> self announce: (WorkAnnoucement finished: #doB).
> self doC.
> self announce: (WorkAnnoucement finished: #doC).
>
> and the specific observer subscribed to this algorithm knows what
> percentage corresponds to each selector. And you could easily plug an
> observer that logs to Transcript.
>
> The announcement can also know
>
> algorithm
>
> self doA.
> self announce: (WorkAnnoucement finished: #doA).
>
>
>
>> where doA, doB, doC are long running computation. So, really generic
>> way to view the progress of something from outside without the
>> knowledge of where to look at and how to interpret these values are
>> not going to fly.
>>
>> -- Yoshiki
>>
>> At Thu, 31 Mar 2011 17:10:58 -0300,
>> Martin Dias wrote:
>> >
>> > Hello
>> >
>> > On Wed, Mar 30, 2011 at 4:24 AM, Denis Kudriashov <dionisiydk at gmail.com>
>> wrote:
>> >
>> > Hello
>> >
>> > I have idea about "meta approach" for implementation of progress
>> tracking of arbitrary method execution.
>> >
>> > Progress tracking (progress bar stuff) is really ortogonal
>> functionallity for method execution. And it would be cool
>> > if we have framework for describing tracking of method execution
>> stuff (like it progress).
>> > This framework should run block of code in background and
>> periodically analize state of this background process
>> > stack. And show this state for user. And so this framework allow
>> track execution of arbitrary code.
>> > Analizing state can search running loops in stack for example and
>> show user status of loop counters.
>> >
>> > I think it is not very hard to implement. But maybe this approach
>> can't be implemented when code jitted
>> >
>> > I like the "meta approach"... but it doesn't look easy to implement for
>> me!
>> > Have you seen something like that implemented? or some paper written?
>> >
>> >
>> > 2011/3/30 Martin Dias <tinchodias at gmail.com>
>> >
>> > Hello
>> >
>> > I have a couple of algorithms and I want to show the progress
>> while they run. I played with the progress bar and
>> > it's okay for my needs.
>> >
>> > The progress bar should be pluggable and decoupled of the
>> algorithms.
>> >
>> > I am writing to you to ask about good designs for my problem. I
>> hope I haven't expressed the problem in a too
>> > abstract way.
>> >
>> > The design I have in mind is a kind of observer pattern: the
>> serialization algorithm publishes information about
>> > the run; a specific listener implements the progress bar for
>> that serialization algorithm, interpreting the
>> > information published.
>> >
>> > Thanks,
>> > Martin
>> >
>> >
>> > [2 <text/plain; us-ascii (7bit)>]
>> >
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20110331/31e768a6/attachment.htm
More information about the Squeak-dev
mailing list
|