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. 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 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. What do you think? -- Pavel
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
Hi Stef, firstly I do not understand why we have SoundService at all when we have AbstractSoundSystem. 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). 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
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
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
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
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.
Would it make sense to rename AppRegistry to ServiceRegistry therefore?
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
-- Mariano http://marianopeck.wordpress.com
On 20.11.2012 13:33, Mariano Martinez Peck wrote:
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.
Would it make sense to rename AppRegistry to ServiceRegistry therefore?
In my mind it would at least. :) That or ServiceProvider, depending on whether one feels the focus should be on its role in registering multiple implementors, or its role in accessing/using those implementors. Cheers, Henry
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
participants (4)
-
Henrik Sperre Johansen -
Mariano Martinez Peck -
Pavel Krivanek -
Stéphane Ducasse