>
> 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 :
>> Sounds ok for me. We should do
e.g. of sound being useful:
With the help of Craig Latta, I've been trying out Spoon.
There is a remote browser for browsing classes remotely.
Well, sound cues while things are transferred over the network are
very useful when debugging.
That's why sound matters in the core of Pharo. And Beeper
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 wrote:
> Hi,
>
> removal of this class is
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
wrote:
> Hi guy
>
> Sound has an AbstractSoundSystem and a Base and Dummy. Then in addition there
> is SounService.
>
> SoundService is no
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