The architecture involved in SoundService/AbstractSoundSystem might seem
like overkill for what is provided/used in the base image.
An external package does exist however, which provides a more capable
soundsystem when installed.
(http://www.squeaksource.com/PharoSound)
On 18.11.2012 09:47, Stéphane Ducasse 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.
More the name of AppRegistry being confusing, what it does is provide
infrastructure for registering providers of a service, and switching
which is currently in use.
In other words, SoundService (due to being an ApprRegistry) can switch
between using multiple SoundSystems.
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.
Because AbstractSoundSystem provides the common interface that is
expected to be supported by a given entry in the SoundService providers
. Whether that warrants including Abstract in the name is debatable I
guess :)
On Sat, Nov 17, 2012 at 9:33 PM, Stéphane Ducasse
<[email protected]> 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.
Outright removal is a bit harsh considering what external users may exist.
It probably deserves either being put in a deprecated package, or moved
to a loadable compat package.
Cheers,
Henry
