Issue and slice created: http://code.google.com/p/pharo/issues/detail?id=6996 -- Pavel On Sun, Nov 18, 2012 at 9:47 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
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.ducasse@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