I wanted to be consistent with the UIManager. We have UIManager, not AbstractUIManager. We register UI managers in UIManager, not in UIRegistry. If some SoundSystem worked now, it only needs to change superclass name and register to different class. Beeper can really be deprecated. Btw. In the proposed changes I used SoundSystem current instead instead of "default" that is used in UIManager. It makes more sense to me because one image can use several sound and ui system at once (e.g. local and remote one that uses Seaside). I would like to see UIManager default to be changed to UIManager current. -- Pavel On Tue, Nov 20, 2012 at 1:28 PM, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no> wrote:
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 <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.
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