Moving Sound into Core

[Casey Harkins]

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 
in core.

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):

    im_msg_received_cb()
    purple_sound_play_event()
    purple_sound_play_required()
    pidgin_sound_play_event()
    purple_sound_play_file()
    purple_sound_play_required()
    pidgin_sound_play_file()

Getting rid of libpurple's notion of sound events, this could easily be 
reduced to:

    im_msg_received_cb()
    purple_sound_play_file()
    pidgin_sound_play_file()


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.


-casey