Why not instead of having sound drivers for PicoGUI, you have a sound server instead - implemented as a client - perhaps with a little frontend inside of pgl. You would apply sound schemes within the sound server itself and the sound server would receive messages to play named sounds (or perhaps it could also receive arbitrary sound data to play directly)
---Is there a way for a client app to trap the widget events from another client or from pgserver itself? If you want to be able to imcorporate sounds into picougi themes, that's fine but IMO is rather counterproductive to your purpose. Suppose someone doesnt want one particular button to make a noise but likes all the other noises that get made -- without knowing how to modify a theme, the user has no way to disable it on the device without disabling all of the sounds. I don't really think you gain anything by packing a bunch of sounds into a .th file vs. a bunch of small .wav files or something anyway. Sounds are pretty large too, so if you don't want a particular noise on your handheld, it makes sense not to have to store it there even when you're never using it. In theory, a sound server would also allow for sound mixing, resampling, multiple formats, et. al. and it would keep the bloat of this kind of code out of pgserver. John -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Micah Dowty Sent: Wednesday, October 17, 2001 12:47 PM To: Pascal Bauermeister Cc: [EMAIL PROTECTED] Subject: Re: [Pgui-devel] Sound Quoting Pascal Bauermeister <[EMAIL PROTECTED]>: ... > I agree about simple sound vs quality sound. These sounds should be > handled by the > server solely, and apps remain unaware of, and I would add the > possibility to have > more places where we can attach a sound, like widget click, dialog > popup, etc. That's a good idea. The sound attachments could be defined by the theme, so that we could have 'sound themes' with sounds for each widget. Of course there will be a config file variable to turn off theme sound :) > > On the other hand I was also mentionning a named sound library provided > to > applications, because I find the theme system extremely well suited to > manage all > this in a way that can be customized. The only sounds it has so far are 'beep' and 'click', but PicoGUI's Driver Messaage mechanism is already capable of allowing apps or parts of pgserver itself to tell drivers to play sounds. We would just need to add more sound constants, and implement sound playing in some drivers. We would definitely need to get sound support into the sdlfb driver for debugging purposes, and write implementations for the 68EZ328 and TuxScreen. > > The sound playing engine is of course below Pgui. Remember that the > console device > (drivers/char/vt.c if I remember well) can play buzzer tones with some > ioctl. For > the sake of simplicity we could start with this device and not care > about OSS & co. That would work when using the framebuffer device on a PC. I don't think many embedded systems implement this though, and SDL is easier to debug with. > > Pascal > -- Only you can prevent creeping featurism! _______________________________________________ Pgui-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/pgui-devel _______________________________________________ Pgui-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/pgui-devel
