That sounds good. Another requirement this has is that applications
should be able to override this configuration for specific processes.
For example, a package might want to ask questions while installing, but
a silent installer might want to answer those questions quietly, without
bugging the user.

I think a good start would be to create a web page with initial
requirements and ideas, and then focus on a first iteration that fixes a
specific important issue - there are a lot of related issues, so its
best to start small. 

Also, I am sure there exist previous systems to deal with similar
requirements in other projects - IIUC, Debians menu system should be an
example. Might be worth reading up their ideas...

Daniel

Rudi Angela <squeak at angelafamily.com> wrote:
> Well why not? Glad to know we have your blessing :-).
> But I would rather give the project a broader scope than just progress 
> bar cleanup:
> Configurable User Engagement [CUE] project: not only will this tackle 
> the issue of feedback during processes (progress bar), but also simple 
> user input needed during the execution of a task, currently done with 
> popup menus.
> With 'Configurable' I mean that the user would be able to define 
> globally, beforehand (e.g. in a preference pane), if and how for 
> instance process progress reporting should be handled (progress bar, 
> audio or log to transcript or file), how to handle e simple choice 
> (popup menu or use preset default or get via HTTP request, etc).
> Any other volunteers?
> 
> Rudi Angela
> 
> 
> On dinsdag, aug 12, 2003, at 17:06 Europe/Amsterdam, Andreas Raab wrote:
> 
> > 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
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >
> >