> > That's why sound matters in the core of Pharo. And Beeper may be > interesting too.
yes! what I mean is that to have Beeper is not a problem to me. But I see what pavel means: no need for SoundSystem and Beeper. > > Phil > > 2013/3/10 stephane ducasse <stephane.duca...@free.fr>: >> Sounds ok for me. We should do that for 3.0alpha :) >> Now I do not care about Beeper removal. >> >> I will split sound in different packages because there are sound and score >> and these are different domains. >> >> Stef >> >> On Mar 10, 2013, at 11:38 AM, Pavel Krivanek <pavel.kriva...@gmail.com> >> wrote: >> >>> Hi, >>> >>> removal of this class is proposed in >>> https://code.google.com/p/pharo/issues/detail?id=6996 >>> >>> -- Pavel >>> >>> >>> On Sun, Mar 10, 2013 at 11:31 AM, Stéphane Ducasse >>> <stephane.duca...@inria.fr> wrote: >>>> Hi guy >>>> >>>> Sound has an AbstractSoundSystem and a Base and Dummy. Then in addition >>>> there is SounService. >>>> >>>> SoundService is not doing much >>>> >>>> soundEnabled >>>> ^ self defaultSoundEnabled >>>> >>>> defaultSoundEnabled >>>> ^DefaultSoundEnabled ifNil: [false] >>>> >>>> toggleSoundEnabling >>>> self soundEnabled: self soundEnabled not >>>> >>>> >>>> >>>> So we could just keep AbstractSoundSystem and deprecate SoundService. >>>> >>>> Stef >>> >> >> >
