> Hi Stef, > > firstly I do not understand why we have SoundService at all when we > have AbstractSoundSystem.
Yes me too :) > And why it is a AppRegistry. AppRegistry > associates some application, tool. It is very confusing to use it for > a sound provider. Then I do not understand why it is named > AbstractSoundSystem and not simply SoundSystem (remember > AbstractString). Yes let us clean all that :) Can you take the lead on that? We could include the sound package in the release. > > On Sat, Nov 17, 2012 at 9:33 PM, Stéphane Ducasse > <stephane.duca...@inria.fr> wrote: >> Hi pavel >> >> In fact the registration default sound system is broken and we should fix it. >> I forgot what is the problem :) >> >>> Hi, >>> >>> I would like to discuss the Beeper class a little bit. The main >>> purpose of this class is to provide Beeper beep message and use >>> SoundService with respect to current sound enabled settings or VM >>> implemented primitive for beeping. >> >> Yes this was the idea and to remove it from smalltalk. >> >>> I think that we should: >>> - move the beep function to UIManager >>> - change all calls of Beeper beep to UIManager default beep >>> - in MorphicUIManager use classic Beeper implementation >>> - move Beeper to System-Sound package >>> - in default UIManager implementation use VM beep primitive >> >> Imagine an headless system without even ui (we did that in the microscopic >> kernel) and the only interaction >> we got at the beginning was to do beep. After we could write a file >> something. >> So moving beep to UI anything worries me. > > On my system the beep primitive does nothing so I use quitPrimitive > for that ;-) > >> >>> There are two main reasons for that. You surely do not want to listen >>> beeping server with Pharo images running remote UIs and I want to make >>> Pharo Kernel independent on SoundService. >> >> I see when we load the sound package beep is not using beep primitive but >> the associated sound. >> May be Beep should have a kind of call back system >> by default invoke its own primitive >> and when sound system is loaded it should invoke sound system via the >> call back >> I thought is was like that because I do not want to link sound to >> kernel that for sure. >> >>> What do you think? >> >> May be we should simply fix the behavior when adding sound service. >> >> Stef >>> >>> -- Pavel >>> >> >> >
