Good! Now that there's three of you why don't you make up the "Progress
Cleanup Project" [PCP] and go ahead and fix those darn things ;-)

Cheers,
  - Andreas

> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org 
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On 
> Behalf Of tblanchard at mac.com
> Sent: Tuesday, August 12, 2003 4:59 PM
> To: The general-purpose Squeak developers list
> Subject: Re: [ENH] FlashCleanup
> 
> 
> Ditto.  I'm not happy about progress bars showing up while using an 
> ObjectStream.
> 
> 
> On Tuesday, August 12, 2003, at 02:21  AM, Claudio Buffa Pace wrote:
> 
> > Hi:
> >
> > I am in full agreement with you.
> >
> > Claudio
> >
> > On Tue, 12 Aug 2003 10:04:28 +0200
> > Rudi Angela <squeak at angelafamily.com> wrote:
> >
> >> I have a problem with the way the progress bar is (was) used in the
> >> Flash package, but the problem is more general.
> >> In general I consider it a bad idea to integrate UI 
> specific parts in
> >> code that is doing such low level things as reading a file. This is
> >> exactly what the progress bar is doing in the flash 
> reader. This makes
> >> the low level code dependent on the higher level UI code, 
> which is in
> >> my view a bad thing.
> >> I would rather have a mechanism where the reader uses a 
> model object
> >> (e.g. a value holder or a more modern mechanism) which it 
> keeps up to
> >> date with respect to the progress. Developers can then 
> decide based on
> >> their specific use whether they need to show a progress bar or any
> >> other applicable UI element, which gets its information by 
> observing
> >> the model.
> >> On the same grounds I disapprove of low level code setting 
> the cursor,
> >> which currently happens in certain file operations.
> >> I have developed an application with Squeak and have run into the 
> >> above
> >> problems a couple of times and found it very annoying. I ended up
> >> adapting low level code just for the sake of my app's UI. 
> This makes 
> >> it
> >> difficult for me to keep my app up to date with the latest image
> >> version.
> >> I propose we start eliminating such code and wherever necessary 
> >> replace
> >> it by model events and such.
> >>
> >> Rudi Angela
> >>
> >> On dinsdag, aug 12, 2003, at 08:50 Europe/Amsterdam, Marcus Denker
> >> wrote:
> >>
> >>> On Mon, Aug 11, 2003 at 10:07:48PM -0400, adspitz at yahoo.ca wrote:
> >>>> from preamble:
> >>>>
> >>>> "Change Set:		FlashCleanup
> >>>> Date:			31 July 2003
> >>>> Author:			Adam Spitz
> >>>>
> >>>> Recategorizes some stuff in order to turn the Flash code into a 
> >>>> single
> >>>> PackageInfo package with no external dependents.
> >>>>
> >>>> Notice that this changeset lumps ProgressMorph in with the Flash
> >>>> stuff.
> >>>> I think this is a bad idea, but I don't know what to do 
> about it. Is
> >>>> there some reason why we shouldn't have a progress-bar 
> thingy that
> >>>> doesn't depend on Flash?"
> >>>> !
> >>> Hmm... Diego posted a changeset long ago:
> >>>
> >>> [ENH] ProgressBarMorph-dgd ( [cd][er][et][sm][approved] )
> >>>
> >>> This cs does:
> >>>
> >>> - rename of FlashProgressMorph to ProgressBarMorph
> >>> - change of ProgressBarMorph (former FlashProgressMorph) class
> >>> category to
> >>>   Morphic-Widgets
> >>> - update of references of FlashProgressMorph
> >>>
> >>> This will be included in 3.7a
> >>>
> >>>
> >>> -- 
> >>> Marcus Denker marcus at ira.uka.de  -- Squeak! http://squeak.de
> >>>
> >>>
> >>
> >>
> >
> 
>