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.
- 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. 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) Cheers, Henry
