Moving Sound into Core
caseyharkins at gmail.com
Sun Jun 17 18:39:18 EDT 2007
John Bailey wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> Christopher Stafford wrote:
>> The msn extras patch I wrote (can't remember the branch it's sitting in)
>> uses it it play voice clips. although that could be done through the UI
>> I guess there's a benefit in being able to target any UI that can play
>> sound easily rather than just doing Pidgin.
> Using the UI to play sounds, unless we keep the sound ui_ops stuff, will never
> happen because it violates the clean break between Pidgin and Libpurple.
Right, I'm in agreement now that some level of sound support must remain
How about removing sound events from core? This would move the
PurpleSoundEventID enum out of sound.h and into gtksound.h (as
PidginSoundEventID) and purple_sound_play_event() could be dropped. In
fact, the enum could probably be dropped all together.
This is a pretty typical execution path for sounds in pidgin (this
example is for sound in response to received-im-msg signal):
Getting rid of libpurple's notion of sound events, this could easily be
The call to purple_sound_play_file() could even be emitted if we're
willing to accept that libpurple will only delegate to ui_ops (not
handing mute or sounds while away type prefs directly).
I don't mind leaving things the way it is, just throwing out some ideas.
More information about the Devel