On Wed, Mar 30, 2011 at 6:12 AM, Henrik Johansen < henrik.s.johan...@veloxit.no> wrote:
> > On Mar 30, 2011, at 7:13 23AM, Daniel Lyons wrote: > > > On Mar 29, 2011, at 6:17 PM, Martin Dias wrote: > > 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. > > > I'm a newcomer here, so I'm sharing my experience with non-Smalltalk > systems and my best guess what would constitute good designs. I hope other > real Smalltalkers will poke some holes in this and point out the right way > to do things! ;) > > The simplest design, IMO, would be this API: > > MyProgressBar>>percentComplete: aNumber > MyProgressBar>>beIndeterminant > MyProgressBar>>beDeterminant > > You would manually invoke percentComplete: with a new percent complete each > time you want to advance the progress bar. I've seen this kind of thing in > practice somewhere. Maybe it was Cocoa? > > The next level of abstraction would be to go a bit more jQuery UI and > remove percentComplete: and use this instead: > > MyProgressBar>>maximum: anInteger > MyProgressBar>>current: anInteger > > Now you'll calculate the progress bar based on some quantity of "tasks" you > want to do. You could even go further and just have: > > MyProgressBar>>incrementProgress > > instead of letting your clients tell you which one they're on. That would > prevent progress bar relapse. Either of these would be easy to implement on > top of the above API using percent. > > The simplest observer-type pattern would be to rely on the built-in > observer/event system and use the stuff from Object's updating protocol or > events-registering or events-triggering. I don't know which one of these is > modern or preferred. Anybody? :) At any rate, they make it possible to > expose a simple object/message protocol as in Polymorph, where your progress > bar widget would be listening for change notifications from your domain > object. Then you can ask the same questions about your model as above, in > terms of whether you want to work in terms of simply percent complete or N/M > or what. > > Another question is whether or not you want to provide a string message > status to go under the progress bar. > > Does this help at all, or did I miss the point? > > — > Daniel Lyons > > I've used Announcements for this in the past, and liked it quite alot. > > I will take a look on that. > - Worker announces WorkCompleted or some such. > Announcement holds details of the work it's done, in my case different > properties of an analysis like leak rate, . > > - GUI/Client is set up before analysis starts, and initialized with the > total work to be done. > Annnouncement handling contains code to estimate how much progress the Work > indicated by it was of the overall total. > > I also used a different client which provided ETA based on a more > sophisticated analysis of the Work announcements. > Wow! I don't need to estimate time but it's very interesting think on that. > > Needless to say, there's no hard dependency on a UI in such a scheme, as > there simply won't be any clients instantiated if you run headless. (well, > unless you make one writing to stdout or something) > > Not sure what would be reasonable to put in a Work-annnouncement intended > as superclass for custom solutions... > In other words, the downside is that this approach doesn't lead to > something you can use out-of-the-box, you always have to do some > customization, either/both to what data you provide, or/and to how you give > feedback. > (In this case, a standard widget using the simplest design you described > is preferrable, btw, the pluggability is done at a different level than the > widget) > > In this moment I am interested in a simple solution, I will not write a framework, but I like the discussion. Thanks! > Cheers, > Henry >
