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.
> 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
>
